Re: [Nek5000-users] Vanishing Jacobian error description
Hi Paul, Here is the rea, usr, & SIZE file I am using. I ran it again without the curved side information and it worked, so I think the problem is somewhere in the curved side section of the rea. The geometry is a square base lofted into a circle in the +z direction. The mesh was generated in gambit. I've developed a matlab code that will take a mesh created in gambit and generate the required REA formatting. I have created some basic shapes to test the matlab portion and the curved side portion, and it worked in most cases (not this one yet). I'm not sure what is going on with the curved side data in this case however. Thanks for looking at this, Michael ----- Original Message ----- From: [email protected] To: "Nekton User List" <[email protected]> Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Vanishing Jacobian error description Michael, The code is trying to check to ensure that the mesh is valid. Sometimes, however, there are other causes for the problem. Can you send a gzip'd rea/usr file, and I can take a look later tonight. Paul On Tue, 20 Apr 2010, [email protected] wrote:
Hi,
I am running into an issue with 'Vanishing Jacobian'. To help understand what the problem is, could someone explain what is meant in the error? Specifically, what it means by "Xth node" of the element. Also, I ran into this issue when I was deforming geometries in the usr file, where one of the elements would overlap another by mistake. However in this case I know there are no overlaps.
Here is a portion:
0 ERROR: Vanishing Jacobian near 91th node of element 69. 1.40692804605498586E-002 -7.79619559165757245E-003 0 xyz: 2.65874E-01 3.54498E-01 2.87050E+00 0 xyz: 2.07855E-01 1.77249E-01 2.87050E+00
0 ERROR: Vanishing Jacobian near 76th node of element 70. 2.59472856644434001E-002 -2.12442422718029170E-002 0 xyz: 2.11655E-01 4.23310E-01 2.62500E+00 0 xyz: 3.54498E-01 1.77249E-01 2.87050E+00
Thanks for any help deciphering this error!
- Michael
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010, [email protected] wrote:
Hi Paul,
Here is the rea, usr, & SIZE file I am using. I ran it again without the curved side information and it worked, so I think the problem is somewhere in the curved side section of the rea.
The geometry is a square base lofted into a circle in the +z direction. The mesh was generated in gambit. I've developed a matlab code that will take a mesh created in gambit and generate the required REA formatting. I have created some basic shapes to test the matlab portion and the curved side portion, and it worked in most cases (not this one yet). I'm not sure what is going on with the curved side data in this case however.
Thanks for looking at this,
Michael
----- Original Message ----- From: [email protected] To: "Nekton User List" <[email protected]> Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Vanishing Jacobian error description
Michael,
The code is trying to check to ensure that the mesh is valid. Sometimes, however, there are other causes for the problem.
Can you send a gzip'd rea/usr file, and I can take a look later tonight.
Paul
On Tue, 20 Apr 2010, [email protected] wrote:
Hi,
I am running into an issue with 'Vanishing Jacobian'. To help understand what the problem is, could someone explain what is meant in the error? Specifically, what it means by "Xth node" of the element. Also, I ran into this issue when I was deforming geometries in the usr file, where one of the elements would overlap another by mistake. However in this case I know there are no overlaps.
Here is a portion:
0 ERROR: Vanishing Jacobian near 91th node of element 69. 1.40692804605498586E-002 -7.79619559165757245E-003 0 xyz: 2.65874E-01 3.54498E-01 2.87050E+00 0 xyz: 2.07855E-01 1.77249E-01 2.87050E+00
0 ERROR: Vanishing Jacobian near 76th node of element 70. 2.59472856644434001E-002 -2.12442422718029170E-002 0 xyz: 2.11655E-01 4.23310E-01 2.62500E+00 0 xyz: 3.54498E-01 1.77249E-01 2.87050E+00
Thanks for any help deciphering this error!
- Michael
_______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Hello! We are considering running some wind-turbine simulations using nek5000 and we are wondering if there is a rotating framework mode in the code? In principle one needs to add some extra forcing terms from the rotation. I wonder if one can do that implicitly. Also, we would like to use some type of pipe flow mesh with azimuthal symmetry. Is that possible? Best regards, Antonios
Hi Antonios, I typically do this by explicitly adding a Coriolis term in userf, and, if I have solid-body rotation, applying a "v " boundary condition with the appropriate rotation to any stationary surfaces. Note that if you have variable density, you should also add a centrifugal force term - this can be important in some cases, though it is often neglected. The Coriolis treatment is explicit and can in some cases lead to a tighter timestep stability constraint than the std. CFL constraint, but I've not found that to be an issue in my (perhaps limited) experience. Paul On Thu, 10 Mar 2011, [email protected] wrote:
Hello! We are considering running some wind-turbine simulations using nek5000 and we are wondering if there is a rotating framework mode in the code? In principle one needs to add some extra forcing terms from the rotation. I wonder if one can do that implicitly. Also, we would like to use some type of pipe flow mesh with azimuthal symmetry. Is that possible? Best regards, Antonios _______________________________________________ Nek5000-users mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
Hi Paul, We will add the two forcing terms in userf. I thought maybe one could do it implicitly but since, as you say, it worked like that it is probably the simplest choice. Thank you. Antonios [email protected] wrote:
Hi Antonios,
I typically do this by explicitly adding a Coriolis term in userf, and, if I have solid-body rotation, applying a "v " boundary condition with the appropriate rotation to any stationary surfaces.
Note that if you have variable density, you should also add a centrifugal force term - this can be important in some cases, though it is often neglected.
The Coriolis treatment is explicit and can in some cases lead to a tighter timestep stability constraint than the std. CFL constraint, but I've not found that to be an issue in my (perhaps limited) experience.
Paul
On Thu, 10 Mar 2011, [email protected] wrote:
Hello! We are considering running some wind-turbine simulations using nek5000 and we are wondering if there is a rotating framework mode in the code? In principle one needs to add some extra forcing terms from the rotation. I wonder if one can do that implicitly. Also, we would like to use some type of pipe flow mesh with azimuthal symmetry. Is that possible? Best regards, Antonios _______________________________________________ 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
participants (1)
-
nek5000-users＠lists.mcs.anl.gov