Hello Neks, I've recently come across an error I haven't seen before. It occurs in the routine "generalev" at the beginning of my run. It looks like the matrix "a" and "b" being fed to the routine have an Infinity or NaN at position (0,0). Are there any ideas of what could cause this type of error? I have attached the logfile to this email. Thanks, -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke
Hi Josh, Have you tried to compile with trapping floating point exception? E.g., the compiler flag for pgf77 is -Ktrap=fp Then you may get a better idea where Inf & Nan first appear... Best, Aleks On Wed, 1 Jun 2011, [email protected] wrote:
Hello Neks,
I've recently come across an error I haven't seen before. It occurs in the routine "generalev" at the beginning of my run.
It looks like the matrix "a" and "b" being fed to the routine have an Infinity or NaN at position (0,0). Are there any ideas of what could cause this type of error?
I have attached the logfile to this email.
Thanks,
-- Josh Camp
"All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke
Hello Aleks, I compiled with the option for trapping a floating point exception, and it gives the message that it trapped the exception in the same spot as before (which is very odd). It might be worth mentioning that if I run in post-processing mode (nsteps=0), it still traps an exception while in userchk (although I don't think it's anything specific in my userchk, as I've used the same .usr file before). The floating point exception occurs when I make a call to col3 with vx and vx (to get the velocity squared), but when I calculate the max and min velocities earlier in userchk, I don't have any issues. My guess is that something with my geometry is wrong, but it passes the various geometry checks I see in the logfile. I'm not sure what is causing the failure at this point--any thoughts? Josh On Wed, Jun 1, 2011 at 6:38 PM, <[email protected]> wrote:
Hi Josh,
Have you tried to compile with trapping floating point exception?
E.g., the compiler flag for pgf77 is
-Ktrap=fp
Then you may get a better idea where Inf & Nan first appear...
Best, Aleks
On Wed, 1 Jun 2011, [email protected] wrote:
Hello Neks,
I've recently come across an error I haven't seen before. It occurs in the routine "generalev" at the beginning of my run.
It looks like the matrix "a" and "b" being fed to the routine have an Infinity or NaN at position (0,0). Are there any ideas of what could cause this type of error?
I have attached the logfile to this email.
Thanks,
-- Josh Camp
"All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
-- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke
Hi Josh, Can you send me your files for this case. (.map, .rea, .usr, and SIZE). I think you are probably right about the geometry being the issue, possibly the boundary conditions. I will take a look at it and see if anything sticks out or if we can reproduce the problem locally. Also, how did you create the mesh for this case? Thanks, Katie On Thu, Jun 2, 2011 at 1:16 PM, <[email protected]> wrote:
Hello Aleks,
I compiled with the option for trapping a floating point exception, and it gives the message that it trapped the exception in the same spot as before (which is very odd).
It might be worth mentioning that if I run in post-processing mode (nsteps=0), it still traps an exception while in userchk (although I don't think it's anything specific in my userchk, as I've used the same .usr file before). The floating point exception occurs when I make a call to col3 with vx and vx (to get the velocity squared), but when I calculate the max and min velocities earlier in userchk, I don't have any issues.
My guess is that something with my geometry is wrong, but it passes the various geometry checks I see in the logfile. I'm not sure what is causing the failure at this point--any thoughts?
Josh
On Wed, Jun 1, 2011 at 6:38 PM, <[email protected]> wrote:
Hi Josh,
Have you tried to compile with trapping floating point exception?
E.g., the compiler flag for pgf77 is
-Ktrap=fp
Then you may get a better idea where Inf & Nan first appear...
Best, Aleks
On Wed, 1 Jun 2011, [email protected] wrote:
Hello Neks,
I've recently come across an error I haven't seen before. It occurs in the routine "generalev" at the beginning of my run.
It looks like the matrix "a" and "b" being fed to the routine have an Infinity or NaN at position (0,0). Are there any ideas of what could cause this type of error?
I have attached the logfile to this email.
Thanks,
-- Josh Camp
"All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
-- Josh Camp
"All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke _______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Hi Josh, Sorry for the delay in processing this... it took awhile for an idea to register here. My guess is that you have an invalid BC --- If you can send a .rea/.usr/SIZE tarfile (e.g., to our ftp site) I can try to inspect it. You could also do this by trapping the offending element from where the code bails in generalev... Sorry for the trouble. Paul On Wed, 1 Jun 2011, [email protected] wrote:
Hello Neks,
I've recently come across an error I haven't seen before. It occurs in the routine "generalev" at the beginning of my run.
It looks like the matrix "a" and "b" being fed to the routine have an Infinity or NaN at position (0,0). Are there any ideas of what could cause this type of error?
I have attached the logfile to this email.
Thanks,
-- Josh Camp
"All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke
Hi Paul, After Katie's response, I took a closer look at the .rea file and we indeed have some incorrect boundary conditions. Thanks for the suggestion! Josh On Fri, Jun 3, 2011 at 4:31 AM, <[email protected]> wrote:
Hi Josh,
Sorry for the delay in processing this... it took awhile for an idea to register here.
My guess is that you have an invalid BC --- If you can send a .rea/.usr/SIZE tarfile (e.g., to our ftp site) I can try to inspect it.
You could also do this by trapping the offending element from where the code bails in generalev...
Sorry for the trouble.
Paul
On Wed, 1 Jun 2011, [email protected] wrote:
Hello Neks,
I've recently come across an error I haven't seen before. It occurs in the routine "generalev" at the beginning of my run.
It looks like the matrix "a" and "b" being fed to the routine have an Infinity or NaN at position (0,0). Are there any ideas of what could cause this type of error?
I have attached the logfile to this email.
Thanks,
-- Josh Camp
"All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
-- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke
Hello Neks, I' trying to solve the MHD equations and encounter the same error reported here: http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-June/001365.html. For testing, I have set up a small grid (384 elements) with B=0 at the boundaries and B=0 as initial conditions, and the error appears before the first timestep. As mentioned in the documentation, I have used the same BC-types for the B Field as for the velocity, so in the .rea file it reads: 5909 ***** PASSIVE SCALAR 1 BOUNDARY CONDITIONS ***** 5910 E 1 1 0.00000 0.00000 0.00000 0.00000 0.00000 5911 E 1 2 0.00000 0.00000 0.00000 0.00000 0.00000 5912 V 1 3 0.00000 0.00000 0.00000 0.00000 0.00000 5913 E 1 4 0.00000 0.00000 0.00000 0.00000 0.00000 5914 E 1 5 0.00000 0.00000 0.00000 0.00000 0.00000 5915 E 1 6 0.00000 0.00000 0.00000 0.00000 0.00000 5916 E 2 1 0.00000 0.00000 0.00000 0.00000 0.00000 5917 E 2 2 0.00000 0.00000 0.00000 0.00000 0.00000 5918 E 2 3 0.00000 0.00000 0.00000 0.00000 0.00000 5919 E 2 4 0.00000 0.00000 0.00000 0.00000 0.00000 5920 E 2 5 0.00000 0.00000 0.00000 0.00000 0.00000 5921 E 2 6 0.00000 0.00000 0.00000 0.00000 0.00000 5922 E 3 1 0.00000 0.00000 0.00000 0.00000 0.00000 5923 E 3 2 0.00000 0.00000 0.00000 0.00000 0.00000 5924 E 3 3 0.00000 0.00000 0.00000 0.00000 0.00000 5925 E 3 4 0.00000 0.00000 0.00000 0.00000 0.00000 5926 E 3 5 0.00000 0.00000 0.00000 0.00000 0.00000 5927 E 3 6 0.00000 0.00000 0.00000 0.00000 0.00000 5928 v 4 1 0.00000 0.00000 0.00000 0.00000 0.00000 5929 E 4 2 0.00000 0.00000 0.00000 0.00000 0.00000 5930 E 4 3 0.00000 0.00000 0.00000 0.00000 0.00000 etc. The thread above mentioned that it was due to incorrect BCs, but unfortunately no more details were given. Cheers, Jan
Hi Jan, On line 5912, velocity BC is written with capital letter V instead of small letter v (as in 5928). If you write velocity with small letter, it'll read the BC in the .usr file (userbc subroutine), otherwise you have to specify the values of velocity in the .rea file. In addition, in the elements (E) BC you have to specify E n1 n2 n3 n4 0 0 0 n1: Number of element n2: side of element n3: element connected n4: side of the element connected. However, you've set n3 and n4 to 0. I hope it helps you. Regards, SL El 01-07-2014 13:56, [email protected] escribió:
Hello Neks, I' trying to solve the MHD equations and encounter the same error reported here: http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-June/001365.html. For testing, I have set up a small grid (384 elements) with B=0 at the boundaries and B=0 as initial conditions, and the error appears before the first timestep. As mentioned in the documentation, I have used the same BC-types for the B Field as for the velocity, so in the .rea file it reads:
5909 ***** PASSIVE SCALAR 1 BOUNDARY CONDITIONS ***** 5910 E 1 1 0.00000 0.00000 0.00000 0.00000 0.00000 5911 E 1 2 0.00000 0.00000 0.00000 0.00000 0.00000 5912 V 1 3 0.00000 0.00000 0.00000 0.00000 0.00000 5913 E 1 4 0.00000 0.00000 0.00000 0.00000 0.00000 5914 E 1 5 0.00000 0.00000 0.00000 0.00000 0.00000 5915 E 1 6 0.00000 0.00000 0.00000 0.00000 0.00000 5916 E 2 1 0.00000 0.00000 0.00000 0.00000 0.00000 5917 E 2 2 0.00000 0.00000 0.00000 0.00000 0.00000 5918 E 2 3 0.00000 0.00000 0.00000 0.00000 0.00000 5919 E 2 4 0.00000 0.00000 0.00000 0.00000 0.00000 5920 E 2 5 0.00000 0.00000 0.00000 0.00000 0.00000 5921 E 2 6 0.00000 0.00000 0.00000 0.00000 0.00000 5922 E 3 1 0.00000 0.00000 0.00000 0.00000 0.00000 5923 E 3 2 0.00000 0.00000 0.00000 0.00000 0.00000 5924 E 3 3 0.00000 0.00000 0.00000 0.00000 0.00000 5925 E 3 4 0.00000 0.00000 0.00000 0.00000 0.00000 5926 E 3 5 0.00000 0.00000 0.00000 0.00000 0.00000 5927 E 3 6 0.00000 0.00000 0.00000 0.00000 0.00000 5928 v 4 1 0.00000 0.00000 0.00000 0.00000 0.00000 5929 E 4 2 0.00000 0.00000 0.00000 0.00000 0.00000 5930 E 4 3 0.00000 0.00000 0.00000 0.00000 0.00000 etc.
The thread above mentioned that it was due to incorrect BCs, but unfortunately no more details were given.
Cheers, Jan
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Hey, thanks for the suggestions. I want to change some of the boundarie values to values =!0 for the actual simulations, that's why there is a mix of small and capital V's. However, userbc sets the bc to zero. I will try to use only one of the two, in case there is a problem with mixing v and V. As far as I know, the specification for the Element-Element-Boundary (E) you mentioned is outdated and handled by the solver. I have run several hydrodynamic simulations with 0 for the options and never encountered any problems. Am 01.07.14 14:51, schrieb [email protected]:
Hi Jan,
On line 5912, velocity BC is written with capital letter V instead of small letter v (as in 5928).
If you write velocity with small letter, it'll read the BC in the .usr file (userbc subroutine), otherwise you have to specify the values of velocity in the .rea file.
In addition, in the elements (E) BC you have to specify
E n1 n2 n3 n4 0 0 0 n1: Number of element n2: side of element n3: element connected n4: side of the element connected.
However, you've set n3 and n4 to 0.
I hope it helps you.
Regards, SL
El 01-07-2014 13:56, [email protected] escribió:
Hello Neks, I' trying to solve the MHD equations and encounter the same error reported here: http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-June/001365.html. For testing, I have set up a small grid (384 elements) with B=0 at the boundaries and B=0 as initial conditions, and the error appears before the first timestep. As mentioned in the documentation, I have used the same BC-types for the B Field as for the velocity, so in the .rea file it reads:
5909 ***** PASSIVE SCALAR 1 BOUNDARY CONDITIONS ***** 5910 E 1 1 0.00000 0.00000 0.00000 0.00000 0.00000 5911 E 1 2 0.00000 0.00000 0.00000 0.00000 0.00000 5912 V 1 3 0.00000 0.00000 0.00000 0.00000 0.00000 5913 E 1 4 0.00000 0.00000 0.00000 0.00000 0.00000 5914 E 1 5 0.00000 0.00000 0.00000 0.00000 0.00000 5915 E 1 6 0.00000 0.00000 0.00000 0.00000 0.00000 5916 E 2 1 0.00000 0.00000 0.00000 0.00000 0.00000 5917 E 2 2 0.00000 0.00000 0.00000 0.00000 0.00000 5918 E 2 3 0.00000 0.00000 0.00000 0.00000 0.00000 5919 E 2 4 0.00000 0.00000 0.00000 0.00000 0.00000 5920 E 2 5 0.00000 0.00000 0.00000 0.00000 0.00000 5921 E 2 6 0.00000 0.00000 0.00000 0.00000 0.00000 5922 E 3 1 0.00000 0.00000 0.00000 0.00000 0.00000 5923 E 3 2 0.00000 0.00000 0.00000 0.00000 0.00000 5924 E 3 3 0.00000 0.00000 0.00000 0.00000 0.00000 5925 E 3 4 0.00000 0.00000 0.00000 0.00000 0.00000 5926 E 3 5 0.00000 0.00000 0.00000 0.00000 0.00000 5927 E 3 6 0.00000 0.00000 0.00000 0.00000 0.00000 5928 v 4 1 0.00000 0.00000 0.00000 0.00000 0.00000 5929 E 4 2 0.00000 0.00000 0.00000 0.00000 0.00000 5930 E 4 3 0.00000 0.00000 0.00000 0.00000 0.00000 etc.
The thread above mentioned that it was due to incorrect BCs, but unfortunately no more details were given.
Cheers, Jan
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Hi Jan and SL, Good point, SL, about the line 5912 but I suspect the problem lies in the fact that in our MHD implementation we only focused on 'v ' type boundary condition and hot on 'V ' so, Jan, I suggest to modify 'V ' to 'v ' and use userbc() to set zero BC for ifield=ifldmhd Let me know if you have any questions. Aleks ________________________________________ From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]] Sent: Tuesday, July 01, 2014 7:51 AM To: [email protected] Subject: Re: [Nek5000-users] Error in generalev with MHD Hi Jan, On line 5912, velocity BC is written with capital letter V instead of small letter v (as in 5928). If you write velocity with small letter, it'll read the BC in the .usr file (userbc subroutine), otherwise you have to specify the values of velocity in the .rea file. In addition, in the elements (E) BC you have to specify E n1 n2 n3 n4 0 0 0 n1: Number of element n2: side of element n3: element connected n4: side of the element connected. However, you've set n3 and n4 to 0. I hope it helps you. Regards, SL El 01-07-2014 13:56, [email protected] escribió:
Hello Neks, I' trying to solve the MHD equations and encounter the same error reported here: http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-June/001365.html. For testing, I have set up a small grid (384 elements) with B=0 at the boundaries and B=0 as initial conditions, and the error appears before the first timestep. As mentioned in the documentation, I have used the same BC-types for the B Field as for the velocity, so in the .rea file it reads:
5909 ***** PASSIVE SCALAR 1 BOUNDARY CONDITIONS ***** 5910 E 1 1 0.00000 0.00000 0.00000 0.00000 0.00000 5911 E 1 2 0.00000 0.00000 0.00000 0.00000 0.00000 5912 V 1 3 0.00000 0.00000 0.00000 0.00000 0.00000 5913 E 1 4 0.00000 0.00000 0.00000 0.00000 0.00000 5914 E 1 5 0.00000 0.00000 0.00000 0.00000 0.00000 5915 E 1 6 0.00000 0.00000 0.00000 0.00000 0.00000 5916 E 2 1 0.00000 0.00000 0.00000 0.00000 0.00000 5917 E 2 2 0.00000 0.00000 0.00000 0.00000 0.00000 5918 E 2 3 0.00000 0.00000 0.00000 0.00000 0.00000 5919 E 2 4 0.00000 0.00000 0.00000 0.00000 0.00000 5920 E 2 5 0.00000 0.00000 0.00000 0.00000 0.00000 5921 E 2 6 0.00000 0.00000 0.00000 0.00000 0.00000 5922 E 3 1 0.00000 0.00000 0.00000 0.00000 0.00000 5923 E 3 2 0.00000 0.00000 0.00000 0.00000 0.00000 5924 E 3 3 0.00000 0.00000 0.00000 0.00000 0.00000 5925 E 3 4 0.00000 0.00000 0.00000 0.00000 0.00000 5926 E 3 5 0.00000 0.00000 0.00000 0.00000 0.00000 5927 E 3 6 0.00000 0.00000 0.00000 0.00000 0.00000 5928 v 4 1 0.00000 0.00000 0.00000 0.00000 0.00000 5929 E 4 2 0.00000 0.00000 0.00000 0.00000 0.00000 5930 E 4 3 0.00000 0.00000 0.00000 0.00000 0.00000 etc.
The thread above mentioned that it was due to incorrect BCs, but unfortunately no more details were given.
Cheers, Jan
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Hello again, I changed all BC's for the magnetic field to 'v' and used userbc to set the value to zero, but the error popped up again. The output reads: 216 Matrix: 0 aa 6 6 6 217 0 aa 7.80579E+01 -6.39449E+01 1.81958E+01 -7.90484E+00 2.16525E+00 0.00000E+00 218 0 aa -6.39449E+01 8.67803E+01 -4.74885E+01 1.84117E+01 -1.07792E+01 5.66872E+00 219 0 aa 1.81958E+01 -4.74885E+01 5.96643E+01 -4.03684E+01 3.02051E+01 -2.06952E+01 220 0 aa -7.90484E+00 1.84117E+01 -4.03684E+01 6.64609E+01 -7.64969E+01 4.76373E+01 221 0 aa 2.16525E+00 -1.07792E+01 3.02051E+01 -7.64969E+01 1.90127E+02 -1.67410E+02 222 0 aa 0.00000E+00 5.66872E+00 -2.06952E+01 4.76373E+01 -1.67410E+02 Infinity 223 224 Matrix: 0 bb 6 6 6 225 0 bb 7.19606E-02 9.84283E-03 -2.07087E-03 -1.02002E-03 7.34397E-04 0.00000E+00 226 0 bb 9.84283E-03 4.07143E-02 -4.22288E-03 7.31377E-03 -3.21920E-03 0.00000E+00 227 0 bb -2.07087E-03 -4.22288E-03 1.05630E-01 -1.61560E-02 6.44826E-03 0.00000E+00 228 0 bb -1.02002E-03 7.31377E-03 -1.61560E-02 1.05960E-01 -6.21764E-03 0.00000E+00 229 0 bb 7.34397E-04 -3.21920E-03 6.44826E-03 -6.21764E-03 5.05023E-02 0.00000E+00 230 0 bb 0.00000E+00 0.00000E+00 0.00000E+00 0.00000E+00 0.00000E+00 NaN 231 232 Matrix: 0 Aeig 6 6 6 233 0 Aeig NaN NaN NaN NaN NaN NaN 234 0 Aeig NaN NaN NaN NaN NaN NaN 235 0 Aeig NaN NaN NaN NaN NaN NaN 236 0 Aeig NaN NaN NaN NaN NaN NaN 237 0 Aeig NaN NaN NaN NaN NaN NaN 238 0 Aeig NaN NaN NaN NaN NaN NaN 239 240 Matrix: 0 Deig 1 6 6 241 0 Deig NaN NaN NaN NaN NaN NaN 242 Error in generalev, info= 5 6 1 243 244 call exitt: dying ... So the problem is probably the NaN and Inf entries. As a next step, I took the gpf example as a starting point, copy pasted my own grid and bc descriptions, set the bc's to zero in the usr-file and removed the Temperaturefield. This produced the same error. Can this be linked to the absence of the temperature field? If I leave out the B-Field the case is running just fine, altough the BC's are the same in the *.rea file. Jan
Hi Nekers, Do you have any experience on generating an axisymmetry mesh via "n2to3"? Now I want to extrude a 2D mesh into a 3D axisymmetry mesh. I found that the rotating axis is y-axis, does anyone know to define the rotating axis into x-directiong? when I keep the default rotating axis (y-direction) , n2to3 only works when there is no edge coincide with the y-axis. in this situation, there is a hole in the center, which is obvious wrong. For example, this is the 2D genbox file. 1 base.rea 2 2 spatial dimension (if negative dump binary re2 and .rea file) 3 1 number of fields 4 # 5 #======================================================================= 6 # 7 box_1 any string with 1st character .ne. "c" or "C" 8 -8 -4 1 nelx,nely,nelz (if <0, length to be equally divided) 9 -0.0 2.0 1. x_0 x_Nelx ratio 10 -0.5 0.5 1. 11 v ,O ,W ,W bc's ! west,east,south,north,bottom,top (fixed 3CHAR format) I want make an axisymmetry tube with the center line is y=0. I know the genbox can extrude a circle face into a tube. but here I want first try to this simple case. Since the mesh is axisymmetric, I choose the boundary type of Z(5) and Z(6) as "E". It can generated the 3D.rea. but after I run genmap, it failed, even I try the much smaller tolerance. NOTE: smaller is better, but generous is more forgiving for bad meshes. 0.1 reading .rea file data ... start locglob_lexico: 8 640 5120 0.10000000000000001 locglob: 1 1 5120 locglob: 2 55 5120 locglob: 3 161 5120 locglob: 1 805 5120 locglob: 2 805 5120 locglob: 3 805 5120 locglob: 1 805 5120 locglob: 2 805 5120 locglob: 3 805 5120 1 2 4 Matrix: SELF!! 1 SELF!! 401 402 401 402 2 SELF!! 506 507 491 492 cont: SELF!! 1 ?? ABORT: SELF-CHK 1 5 1 0 Try to tighten the mesh tolerance! 0 quit ========================================== so does anyone know how to solve it or use some third party tools? thanks Alberto.
participants (1)
-
nek5000-users＠lists.mcs.anl.gov