From nek5000-users at lists.mcs.anl.gov Thu Apr 1 11:38:40 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 01 Apr 2010 18:38:40 +0200 Subject: [Nek5000-users] 2 and a half dimentions with nekton? Message-ID: <1270139920.5262.101.camel@flubio04.dicat.unige.it> Dear Paul & Stefar, One question: In the case of the perturbation mode if one has a base flow with one homogeneous direction the perturbation equation for three dimensional disturbances (perturbation fields) can be solved in Fourier space with one fourier mode in that direction and then only one point is necessary instead of 3 X N (the polynomial order) and it becomes as expensive as a 2D simulation. I wonder if a feature like that exists in the current version of the code or maybe in an older one. hint(?) : Maybe one could use two separate perturbation fields to store the "real" and "imaginary" part of the perturbation. Regards & happy Easter! Antonios ps: This procedure is often termed 2.5D, hence the subject text. -- --------------------------------------------------------------------------------------------- Antonios Monokrousos Department of Mechanics email: antonios at mech.kth.se Royal Institute of Technology (KTH) phone: +46 8 790 68 76 Osquars Backe 18 telefax: +46 8 796 98 50 SE-100 44 Stockholm, SWEDEN From nek5000-users at lists.mcs.anl.gov Thu Apr 1 11:54:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 1 Apr 2010 11:54:34 -0500 (CDT) Subject: [Nek5000-users] 2 and a half dimentions with nekton? In-Reply-To: <1270139920.5262.101.camel@flubio04.dicat.unige.it> References: <1270139920.5262.101.camel@flubio04.dicat.unige.it> Message-ID: Dear Antonios, Your suggestion to use two perturbation modes to represent the real and imaginary parts is an excellent one - I think you could code this in a fairly std way, particularly if you are not using the characteristics time stepping (i.e., if you are using the BDF/EXT scheme, which is standard). In that case, one would only need to add to ffx and ffy the additional terms associated with the interactions of the sin/cosine terms. The timestepper treats ffx and ffy w/ exactly the same extrapolation as the nonlinear terms, so everything should go through w/o much effort. Best regards, Paul On Thu, 1 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul & Stefar, > > One question: In the case of the perturbation mode if one has a base > flow with one homogeneous direction the perturbation equation for three > dimensional disturbances (perturbation fields) can be solved in Fourier > space with one fourier mode in that direction and then only one point is > necessary instead of 3 X N (the polynomial order) and it becomes as > expensive as a 2D simulation. I wonder if a feature like that exists in > the current version of the code or maybe in an older one. > > hint(?) : Maybe one could use two separate perturbation fields to store > the "real" and "imaginary" part of the perturbation. > > > Regards & happy Easter! > Antonios > > ps: This procedure is often termed 2.5D, hence the subject text. > > -- > --------------------------------------------------------------------------------------------- > Antonios Monokrousos > Department of Mechanics email: antonios at mech.kth.se > Royal Institute of Technology (KTH) phone: +46 8 790 68 76 > Osquars Backe 18 telefax: +46 8 796 98 50 > SE-100 44 Stockholm, SWEDEN > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Apr 2 06:14:08 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 02 Apr 2010 13:14:08 +0200 Subject: [Nek5000-users] surface tension (Marangoni effect) driven flows Message-ID: <1270206848.11360.68.camel@localhost.localdomain> Hello all, I am interested in the opinion of users and developers as to whether it is practical to use Nek5000 for a "two-phase" flow problem. I write "two-phase" since the interface between the two fluids is fixed, with only the shear stress and tangential velocity matched there (normal velocity being zero) and temperature and normal heat flux. In addition, on the liquid side of the interface there is a shear stress proportional to the temperature gradient along the interface (Marangoni effect). Also, am I correct in understanding that all components of velocity are stored at the same location (the Gauss?Lobatto?Legendre points), while the pressure is located at the Gauss?Legendre points? This being in contrast to a MAC type staggered grid, where each velocity component resides at different spatial locations. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Apr 2 06:30:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 2 Apr 2010 13:30:00 +0200 Subject: [Nek5000-users] surface tension (Marangoni effect) driven flows In-Reply-To: <1270206848.11360.68.camel@localhost.localdomain> References: <1270206848.11360.68.camel@localhost.localdomain> Message-ID: <793F89F0-80D0-47F3-9717-6BB9F3B3FAFC@lav.mavt.ethz.ch> Hi Frank, I guess you have to deal with a sharp interface in your two-phase flow problem. The question is how do you resolve this interface having in mind (a) accuracy and (b) boundness (stability). High-order methods are typically less robust to under-resolution and you need to play some tricks to get a bounded solution (e.g. using flux-limiters). How do you plan to tackle this problem? -Stefan On Apr 2, 2010, at 1:14 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I am interested in the opinion of users and developers as to whether it > is practical to use Nek5000 for a "two-phase" flow problem. I write > "two-phase" since the interface between the two fluids is fixed, with > only the shear stress and tangential velocity matched there (normal > velocity being zero) and temperature and normal heat flux. In addition, > on the liquid side of the interface there is a shear stress proportional > to the temperature gradient along the interface (Marangoni effect). > > Also, am I correct in understanding that all components of velocity are > stored at the same location (the Gauss?Lobatto?Legendre points), while > the pressure is located at the Gauss?Legendre points? This being in > contrast to a MAC type staggered grid, where each velocity component > resides at different spatial locations. > > Cheers, > Frank > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 2 06:49:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 02 Apr 2010 13:49:12 +0200 Subject: [Nek5000-users] surface tension (Marangoni effect) driven flows In-Reply-To: <793F89F0-80D0-47F3-9717-6BB9F3B3FAFC@lav.mavt.ethz.ch> References: <1270206848.11360.68.camel@localhost.localdomain> <793F89F0-80D0-47F3-9717-6BB9F3B3FAFC@lav.mavt.ethz.ch> Message-ID: <1270208952.11360.96.camel@localhost.localdomain> On Fri, 2010-04-02 at 13:30 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > I guess you have to deal with a sharp interface in your two-phase flow problem. > The question is how do you resolve this interface having in mind (a) accuracy and (b) boundness (stability). > > High-order methods are typically less robust to under-resolution and you need to play some tricks to get a bounded solution (e.g. using flux-limiters). > > How do you plan to tackle this problem? Hello Stefan, The interface does not need to be resolved, it is known. The situation is the following. There is a liquid drop surrounded by gas. The surface tension of the liquid is high enough that the shape of the liquid (i.e., the interface) is not affected by the flow in the liquid or in the gas. Therefore the shape of the interface is determined entirely by the contact angle and gravity. However, the gas "sees" the liquid and vice versa, thanks to the continuity of velocity, temperature, tangential stress and heat flux across the interface. It is worth noting that, taking an incompressible gas and liquid, the pressure level of the gas is not coupled to that of the liquid. So the problem can be thought of as two separate simulations which have a boundary across which they share the above boundary conditions. So not a true two-phase flow. Cheers, Frank > > > -Stefan > > > On Apr 2, 2010, at 1:14 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > > > I am interested in the opinion of users and developers as to whether it > > is practical to use Nek5000 for a "two-phase" flow problem. I write > > "two-phase" since the interface between the two fluids is fixed, with > > only the shear stress and tangential velocity matched there (normal > > velocity being zero) and temperature and normal heat flux. In addition, > > on the liquid side of the interface there is a shear stress proportional > > to the temperature gradient along the interface (Marangoni effect). > > > > Also, am I correct in understanding that all components of velocity are > > stored at the same location (the Gauss?Lobatto?Legendre points), while > > the pressure is located at the Gauss?Legendre points? This being in > > contrast to a MAC type staggered grid, where each velocity component > > resides at different spatial locations. > > > > Cheers, > > Frank > > > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Apr 2 07:02:42 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 2 Apr 2010 14:02:42 +0200 Subject: [Nek5000-users] surface tension (Marangoni effect) driven flows In-Reply-To: <1270208952.11360.96.camel@localhost.localdomain> References: <1270206848.11360.68.camel@localhost.localdomain> <793F89F0-80D0-47F3-9717-6BB9F3B3FAFC@lav.mavt.ethz.ch> <1270208952.11360.96.camel@localhost.localdomain> Message-ID: Ok I see. It's hard to say if NEK can handle a problem like this. Do you know what's needed on a solver level to tackle such a problem? I think you want to run two NEK instances which are coupled through an interface boundary condition, right? Stefan On Apr 2, 2010, at 1:49 PM, nek5000-users at lists.mcs.anl.gov wrote: > On Fri, 2010-04-02 at 13:30 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Frank, >> >> I guess you have to deal with a sharp interface in your two-phase flow problem. >> The question is how do you resolve this interface having in mind (a) accuracy and (b) boundness (stability). >> >> High-order methods are typically less robust to under-resolution and you need to play some tricks to get a bounded solution (e.g. using flux-limiters). >> >> How do you plan to tackle this problem? > > Hello Stefan, > > The interface does not need to be resolved, it is known. The situation > is the following. There is a liquid drop surrounded by gas. The > surface tension of the liquid is high enough that the shape of the > liquid (i.e., the interface) is not affected by the flow in the liquid > or in the gas. Therefore the shape of the interface is determined > entirely by the contact angle and gravity. However, the gas "sees" the > liquid and vice versa, thanks to the continuity of velocity, > temperature, tangential stress and heat flux across the interface. It > is worth noting that, taking an incompressible gas and liquid, the > pressure level of the gas is not coupled to that of the liquid. So the > problem can be thought of as two separate simulations which have a > boundary across which they share the above boundary conditions. So not > a true two-phase flow. > > Cheers, > Frank > >> >> >> -Stefan >> >> >> On Apr 2, 2010, at 1:14 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >>> >>> I am interested in the opinion of users and developers as to whether it >>> is practical to use Nek5000 for a "two-phase" flow problem. I write >>> "two-phase" since the interface between the two fluids is fixed, with >>> only the shear stress and tangential velocity matched there (normal >>> velocity being zero) and temperature and normal heat flux. In addition, >>> on the liquid side of the interface there is a shear stress proportional >>> to the temperature gradient along the interface (Marangoni effect). >>> >>> Also, am I correct in understanding that all components of velocity are >>> stored at the same location (the Gauss?Lobatto?Legendre points), while >>> the pressure is located at the Gauss?Legendre points? This being in >>> contrast to a MAC type staggered grid, where each velocity component >>> resides at different spatial locations. >>> >>> Cheers, >>> Frank >>> >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 2 07:17:42 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 02 Apr 2010 14:17:42 +0200 Subject: [Nek5000-users] surface tension (Marangoni effect) driven flows In-Reply-To: References: <1270206848.11360.68.camel@localhost.localdomain> <793F89F0-80D0-47F3-9717-6BB9F3B3FAFC@lav.mavt.ethz.ch> <1270208952.11360.96.camel@localhost.localdomain> Message-ID: <1270210662.11360.110.camel@localhost.localdomain> On Fri, 2010-04-02 at 14:02 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Ok I see. It's hard to say if NEK can handle a problem like this. > Do you know what's needed on a solver level to tackle such a problem? Hi Stefan, My idea of the coupling would be to (at each time step): 1) solve the liquid using some guess for the velocity and temperature at the interface 2) define the tangential stress at and heat flux across the interface from using the values of the velocity and temperature in the liquid 3) using the tangential stress and heat flux from 2 as boundary conditions, solve for the gas (including at the interface). 4) using the velocity and temperature at the interface found in 3, goto 1 and repeat till convergence. > > I think you want to run two NEK instances which are coupled through an interface boundary condition, right? Yes, that would be the goal. Each instance would have different fluid properties, and be connected to the other through the mentioned BCs at the interface. Are you aware of any uses of Nek5000 to solve surface tension (Marangoni effect) driven flows? Cheers, Frank > > Stefan > > > On Apr 2, 2010, at 1:49 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > On Fri, 2010-04-02 at 13:30 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Frank, > >> > >> I guess you have to deal with a sharp interface in your two-phase flow problem. > >> The question is how do you resolve this interface having in mind (a) accuracy and (b) boundness (stability). > >> > >> High-order methods are typically less robust to under-resolution and you need to play some tricks to get a bounded solution (e.g. using flux-limiters). > >> > >> How do you plan to tackle this problem? > > > > Hello Stefan, > > > > The interface does not need to be resolved, it is known. The situation > > is the following. There is a liquid drop surrounded by gas. The > > surface tension of the liquid is high enough that the shape of the > > liquid (i.e., the interface) is not affected by the flow in the liquid > > or in the gas. Therefore the shape of the interface is determined > > entirely by the contact angle and gravity. However, the gas "sees" the > > liquid and vice versa, thanks to the continuity of velocity, > > temperature, tangential stress and heat flux across the interface. It > > is worth noting that, taking an incompressible gas and liquid, the > > pressure level of the gas is not coupled to that of the liquid. So the > > problem can be thought of as two separate simulations which have a > > boundary across which they share the above boundary conditions. So not > > a true two-phase flow. > > > > Cheers, > > Frank > > > >> > >> > >> -Stefan > >> > >> > >> On Apr 2, 2010, at 1:14 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hello all, > >>> > >>> I am interested in the opinion of users and developers as to whether it > >>> is practical to use Nek5000 for a "two-phase" flow problem. I write > >>> "two-phase" since the interface between the two fluids is fixed, with > >>> only the shear stress and tangential velocity matched there (normal > >>> velocity being zero) and temperature and normal heat flux. In addition, > >>> on the liquid side of the interface there is a shear stress proportional > >>> to the temperature gradient along the interface (Marangoni effect). > >>> > >>> Also, am I correct in understanding that all components of velocity are > >>> stored at the same location (the Gauss?Lobatto?Legendre points), while > >>> the pressure is located at the Gauss?Legendre points? This being in > >>> contrast to a MAC type staggered grid, where each velocity component > >>> resides at different spatial locations. > >>> > >>> Cheers, > >>> Frank > >>> > >>> -- > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>> Technische Universit?t Wien (Technical University of Vienna) > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>> Mechanics and Heat Transfer) > >>> Resselgasse 3 > >>> 1040 Wien > >>> Tel: +4315880132232 > >>> Fax: +4315880132299 > >>> Cell:+436765203470 > >>> fmuldoo (skype) > >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>> > >>> _______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Apr 2 07:23:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 02 Apr 2010 14:23:00 +0200 Subject: [Nek5000-users] 2 and a half dimentions with nekton? In-Reply-To: References: <1270139920.5262.101.camel@flubio04.dicat.unige.it> Message-ID: <1270210980.5262.106.camel@flubio04.dicat.unige.it> Sounds good! Thanks for the advice. I will look into it and let you know. Antonios On Thu, 2010-04-01 at 11:54 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Dear Antonios, > > > Your suggestion to use two perturbation modes to represent > the real and imaginary parts is an excellent one - I think > you could code this in a fairly std way, particularly if you > are not using the characteristics time stepping (i.e., if you > are using the BDF/EXT scheme, which is standard). In that case, > one would only need to add to ffx and ffy the additional > terms associated with the interactions of the sin/cosine > terms. The timestepper treats ffx and ffy w/ exactly the > same extrapolation as the nonlinear terms, so everything should > go through w/o much effort. > > Best regards, > > Paul > > > On Thu, 1 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Dear Paul & Stefar, > > > > One question: In the case of the perturbation mode if one has a base > > flow with one homogeneous direction the perturbation equation for three > > dimensional disturbances (perturbation fields) can be solved in Fourier > > space with one fourier mode in that direction and then only one point is > > necessary instead of 3 X N (the polynomial order) and it becomes as > > expensive as a 2D simulation. I wonder if a feature like that exists in > > the current version of the code or maybe in an older one. > > > > hint(?) : Maybe one could use two separate perturbation fields to store > > the "real" and "imaginary" part of the perturbation. > > > > > > Regards & happy Easter! > > Antonios > > > > ps: This procedure is often termed 2.5D, hence the subject text. > > > > -- > > --------------------------------------------------------------------------------------------- > > Antonios Monokrousos > > Department of Mechanics email: antonios at mech.kth.se > > Royal Institute of Technology (KTH) phone: +46 8 790 68 76 > > Osquars Backe 18 telefax: +46 8 796 98 50 > > SE-100 44 Stockholm, SWEDEN > > > > > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 2 07:30:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 2 Apr 2010 14:30:52 +0200 Subject: [Nek5000-users] surface tension (Marangoni effect) driven flows In-Reply-To: <1270210662.11360.110.camel@localhost.localdomain> References: <1270206848.11360.68.camel@localhost.localdomain> <793F89F0-80D0-47F3-9717-6BB9F3B3FAFC@lav.mavt.ethz.ch> <1270208952.11360.96.camel@localhost.localdomain> <1270210662.11360.110.camel@localhost.localdomain> Message-ID: <7954DC24-7655-4FF6-80F1-029C75710890@lav.mavt.ethz.ch> Yes, I think we can handle that using our new NEK-NEK capabilities! The motivation for developing the NEK-NEK feature was slightly different though. The plan was to enable simulations with complex geometries and/or to have local high resolution zones without suffering from topological constraints. No, I don't think we have a customer dealing with surface tension driven flows. But I could be wrong. @Paul: you may want to comment on that? -Stefan On Apr 2, 2010, at 2:17 PM, nek5000-users at lists.mcs.anl.gov wrote: > On Fri, 2010-04-02 at 14:02 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Ok I see. It's hard to say if NEK can handle a problem like this. >> Do you know what's needed on a solver level to tackle such a problem? > > Hi Stefan, > > My idea of the coupling would be to (at each time step): > > 1) solve the liquid using some guess for the velocity and temperature > at the interface > > 2) define the tangential stress at and heat flux across the interface > from using the values of the velocity and temperature in the liquid > > 3) using the tangential stress and heat flux from 2 as boundary > conditions, solve for the gas (including at the interface). > > 4) using the velocity and temperature at the interface found in 3, goto > 1 and repeat till convergence. > > >> >> I think you want to run two NEK instances which are coupled through an interface boundary condition, right? > > Yes, that would be the goal. Each instance would have different fluid > properties, and be connected to the other through the mentioned BCs at > the interface. > > Are you aware of any uses of Nek5000 to solve surface tension (Marangoni > effect) driven flows? > > Cheers, > Frank > >> >> Stefan >> >> >> On Apr 2, 2010, at 1:49 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> On Fri, 2010-04-02 at 13:30 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Hi Frank, >>>> >>>> I guess you have to deal with a sharp interface in your two-phase flow problem. >>>> The question is how do you resolve this interface having in mind (a) accuracy and (b) boundness (stability). >>>> >>>> High-order methods are typically less robust to under-resolution and you need to play some tricks to get a bounded solution (e.g. using flux-limiters). >>>> >>>> How do you plan to tackle this problem? >>> >>> Hello Stefan, >>> >>> The interface does not need to be resolved, it is known. The situation >>> is the following. There is a liquid drop surrounded by gas. The >>> surface tension of the liquid is high enough that the shape of the >>> liquid (i.e., the interface) is not affected by the flow in the liquid >>> or in the gas. Therefore the shape of the interface is determined >>> entirely by the contact angle and gravity. However, the gas "sees" the >>> liquid and vice versa, thanks to the continuity of velocity, >>> temperature, tangential stress and heat flux across the interface. It >>> is worth noting that, taking an incompressible gas and liquid, the >>> pressure level of the gas is not coupled to that of the liquid. So the >>> problem can be thought of as two separate simulations which have a >>> boundary across which they share the above boundary conditions. So not >>> a true two-phase flow. >>> >>> Cheers, >>> Frank >>> >>>> >>>> >>>> -Stefan >>>> >>>> >>>> On Apr 2, 2010, at 1:14 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hello all, >>>>> >>>>> I am interested in the opinion of users and developers as to whether it >>>>> is practical to use Nek5000 for a "two-phase" flow problem. I write >>>>> "two-phase" since the interface between the two fluids is fixed, with >>>>> only the shear stress and tangential velocity matched there (normal >>>>> velocity being zero) and temperature and normal heat flux. In addition, >>>>> on the liquid side of the interface there is a shear stress proportional >>>>> to the temperature gradient along the interface (Marangoni effect). >>>>> >>>>> Also, am I correct in understanding that all components of velocity are >>>>> stored at the same location (the Gauss?Lobatto?Legendre points), while >>>>> the pressure is located at the Gauss?Legendre points? This being in >>>>> contrast to a MAC type staggered grid, where each velocity component >>>>> resides at different spatial locations. >>>>> >>>>> Cheers, >>>>> Frank >>>>> >>>>> -- >>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>>> Technische Universit?t Wien (Technical University of Vienna) >>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>>> Mechanics and Heat Transfer) >>>>> Resselgasse 3 >>>>> 1040 Wien >>>>> Tel: +4315880132232 >>>>> Fax: +4315880132299 >>>>> Cell:+436765203470 >>>>> fmuldoo (skype) >>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 2 10:52:51 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 02 Apr 2010 17:52:51 +0200 Subject: [Nek5000-users] surface tension (Marangoni effect) driven flows In-Reply-To: <7954DC24-7655-4FF6-80F1-029C75710890@lav.mavt.ethz.ch> References: <1270206848.11360.68.camel@localhost.localdomain> <793F89F0-80D0-47F3-9717-6BB9F3B3FAFC@lav.mavt.ethz.ch> <1270208952.11360.96.camel@localhost.localdomain> <1270210662.11360.110.camel@localhost.localdomain> <7954DC24-7655-4FF6-80F1-029C75710890@lav.mavt.ethz.ch> Message-ID: <1270223571.11360.119.camel@localhost.localdomain> On Fri, 2010-04-02 at 14:30 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Yes, I think we can handle that using our new NEK-NEK capabilities! Hi Stefan, That is very nice to hear! Question; what does NEK-NEK stand for? Cheers, Frank > The motivation for developing the NEK-NEK feature was slightly different though. The plan was to enable simulations with complex geometries and/or to have local high resolution zones without suffering from topological constraints. > > No, I don't think we have a customer dealing with surface tension driven flows. But I could be wrong. > @Paul: you may want to comment on that? > > -Stefan > > On Apr 2, 2010, at 2:17 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > On Fri, 2010-04-02 at 14:02 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Ok I see. It's hard to say if NEK can handle a problem like this. > >> Do you know what's needed on a solver level to tackle such a problem? > > > > Hi Stefan, > > > > My idea of the coupling would be to (at each time step): > > > > 1) solve the liquid using some guess for the velocity and temperature > > at the interface > > > > 2) define the tangential stress at and heat flux across the interface > > from using the values of the velocity and temperature in the liquid > > > > 3) using the tangential stress and heat flux from 2 as boundary > > conditions, solve for the gas (including at the interface). > > > > 4) using the velocity and temperature at the interface found in 3, goto > > 1 and repeat till convergence. > > > > > >> > >> I think you want to run two NEK instances which are coupled through an interface boundary condition, right? > > > > Yes, that would be the goal. Each instance would have different fluid > > properties, and be connected to the other through the mentioned BCs at > > the interface. > > > > Are you aware of any uses of Nek5000 to solve surface tension (Marangoni > > effect) driven flows? > > > > Cheers, > > Frank > > > >> > >> Stefan > >> > >> > >> On Apr 2, 2010, at 1:49 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> On Fri, 2010-04-02 at 13:30 +0200, nek5000-users at lists.mcs.anl.gov > >>> wrote: > >>>> Hi Frank, > >>>> > >>>> I guess you have to deal with a sharp interface in your two-phase flow problem. > >>>> The question is how do you resolve this interface having in mind (a) accuracy and (b) boundness (stability). > >>>> > >>>> High-order methods are typically less robust to under-resolution and you need to play some tricks to get a bounded solution (e.g. using flux-limiters). > >>>> > >>>> How do you plan to tackle this problem? > >>> > >>> Hello Stefan, > >>> > >>> The interface does not need to be resolved, it is known. The situation > >>> is the following. There is a liquid drop surrounded by gas. The > >>> surface tension of the liquid is high enough that the shape of the > >>> liquid (i.e., the interface) is not affected by the flow in the liquid > >>> or in the gas. Therefore the shape of the interface is determined > >>> entirely by the contact angle and gravity. However, the gas "sees" the > >>> liquid and vice versa, thanks to the continuity of velocity, > >>> temperature, tangential stress and heat flux across the interface. It > >>> is worth noting that, taking an incompressible gas and liquid, the > >>> pressure level of the gas is not coupled to that of the liquid. So the > >>> problem can be thought of as two separate simulations which have a > >>> boundary across which they share the above boundary conditions. So not > >>> a true two-phase flow. > >>> > >>> Cheers, > >>> Frank > >>> > >>>> > >>>> > >>>> -Stefan > >>>> > >>>> > >>>> On Apr 2, 2010, at 1:14 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hello all, > >>>>> > >>>>> I am interested in the opinion of users and developers as to whether it > >>>>> is practical to use Nek5000 for a "two-phase" flow problem. I write > >>>>> "two-phase" since the interface between the two fluids is fixed, with > >>>>> only the shear stress and tangential velocity matched there (normal > >>>>> velocity being zero) and temperature and normal heat flux. In addition, > >>>>> on the liquid side of the interface there is a shear stress proportional > >>>>> to the temperature gradient along the interface (Marangoni effect). > >>>>> > >>>>> Also, am I correct in understanding that all components of velocity are > >>>>> stored at the same location (the Gauss?Lobatto?Legendre points), while > >>>>> the pressure is located at the Gauss?Legendre points? This being in > >>>>> contrast to a MAC type staggered grid, where each velocity component > >>>>> resides at different spatial locations. > >>>>> > >>>>> Cheers, > >>>>> Frank > >>>>> > >>>>> -- > >>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>>>> Technische Universit?t Wien (Technical University of Vienna) > >>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>>>> Mechanics and Heat Transfer) > >>>>> Resselgasse 3 > >>>>> 1040 Wien > >>>>> Tel: +4315880132232 > >>>>> Fax: +4315880132299 > >>>>> Cell:+436765203470 > >>>>> fmuldoo (skype) > >>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>>>> > >>>>> _______________________________________________ > >>>>> Nek5000-users mailing list > >>>>> Nek5000-users at lists.mcs.anl.gov > >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>> > >>>> _______________________________________________ > >>>> Nek5000-users mailing list > >>>> Nek5000-users at lists.mcs.anl.gov > >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>> -- > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>> Technische Universit?t Wien (Technical University of Vienna) > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>> Mechanics and Heat Transfer) > >>> Resselgasse 3 > >>> 1040 Wien > >>> Tel: +4315880132232 > >>> Fax: +4315880132299 > >>> Cell:+436765203470 > >>> fmuldoo (skype) > >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>> > >>> _______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Sat Apr 3 20:37:14 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 3 Apr 2010 20:37:14 -0500 (CDT) Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: <1081451299.2785281270344963043.JavaMail.root@neo-mail-3> Message-ID: <462124232.2785491270345034024.JavaMail.root@neo-mail-3> Hi Paul, Were you able to figure out the issue with Markus's midpoint case?? Thank you for looking into this! Kindly, Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, March 29, 2010 11:37:43 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Representing Curved Side in any plane Hi Markus, Thanks -- I'll check into it. Paul On Mon, 29 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > just double-checked, that's what I did. I only ran it for one time step without > any meaningful physics, though. > Attached are all case files. The nek version I am using is revision 456. > > Markus > > > > Quoting nek5000-users at lists.mcs.anl.gov: > >> >> Hi Markus, >> >> Did you visualize this with VisIt and with the geometry >> put out into (at least) the first .fld or .f file ? >> >> Paul >> >> >> On Mon, 29 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> I was looking into the midpoint feature and generated a cube (1 element, x, >>> y, z from 0 to 1) in prenek, then converted all edges to the midpoint >>> notation with prenek, and then manipulated one edge in the rea file. This >> is >>> the resulting curved side section: >>> ?***** CURVED SIDE DATA ***** >>> ? ? ? ?12 Curved sides follow IEDGE,IEL,CURVE(I),I=1,5, CCURVE >>> ?1 ?1 ?0.500000 ? ? ? 0.00000 ? ? ? 0.00000 ? ? ? 0.00000 0.00000 ? ? m >>> ?2 ?1 ? 1.10000 ? ? ?0.500000 ? ? ? 0.00000 ? ? ? 0.00000 0.00000 ? ? m >>> . >>> . >>> . >>> 10 ?1 ? 1.00000 ? ? -0.500000 ? ? ?0.500000 ? ? ? 0.00000 0.00000 ? ? m >>> 11 ?1 ? 1.00000 ? ? ? 1.00000 ? ? ?0.500000 ? ? ? 0.00000 0.00000 ? ? m >>> 12 ?1 ? 0.00000 ? ? ? 1.00000 ? ? ?0.500000 ? ? ? 0.00000 0.00000 ? ? m >>> >>> where edge 10 is supposedly not a straight line any more. >>> >>> When I run this in nek, however, the cube still comes out with straight >>> edges. >>> >>> Are there any other parameters I need to set? >>> >>> I checked out the most recent nek version and overcame compilation issues >>> with gcc-gfortran 4.4.3-4.fc12 from the fedora 12 repository. >>> >>> Thanks, >>> Markus >>> >>> >>> nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>> >>>> Michael, >>>> >>>> I've only recently added general purpose midside-node support, >>>> which puts a point in 3-space for any one of the 12 edges and >>>> nek then fits a parabola to this. >>>> >>>> I'll set up an example that demos this. ?The feature has limited >>>> support at the moment -- but does work in nek5000 and generates >>>> correct geometry. >>>> >>>> Depending on what you are after, there may be other ways to >>>> generate the geometry. ? One of my favorite techniques is to >>>> project a given input geometry onto the desired surface. >>>> >>>> >>>> Paul >>>> >>>> >>>> >>>> On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>> >>>> >>>> ?Hello Users, >>>> >>>> >>>> >>>> >>>> ?My question is in regard to the curved side data section in the REA >>>> file. ?I know that the first 3 terms describe the side, element, and >>>> radius, but there are several other numbers that are currently zero, and >>>> then the letter C. >>>> >>>> >>>> >>>> ?Background for the question: I have a situation where I would like to >>>> curve an element edge in any plane. I know this is possible from >>>> previous posts regarding a sphere.rea. >>>> >>>> >>>> >>>> ?I know that with two points and a radius, that is enough to describe a >>>> circle in a plane. ?But lets say I have a side where 2 pts lie on the >>>> XY plane, but the center of the circle is located on the YZ plane for >>>> example... the question is how to represent this in the REA. In the REA >>>> you just give the element side ( 2 pts ) and the radius, which does fix >>>> the circle center but the plane that contains the center is not >>>> fixed. ?So what I am wondering is what the other numbers in this >>>> section do...if you could say, give the center instead of the radius, or >>>> give a third point with the other 2 pts in the element side to fully >>>> define the circle and plane. >>>> >>>> >>>> >>>> ?Also, Is it possible to curve the remaining 4 sides of the element >>>> (edges 9, 10, 11, 12 that would be in the "z" direction) in the same >>>> manner as edges 1-8? Thanks for any input on this matter! >>>> >>>> >>>> >>>> ?Regards, >>>> >>>> ?Michael Meador >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 5 21:29:33 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 5 Apr 2010 21:29:33 -0500 (CDT) Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: <462124232.2785491270345034024.JavaMail.root@neo-mail-3> References: <462124232.2785491270345034024.JavaMail.root@neo-mail-3> Message-ID: Hi, I've just added the midside-node support to the current svn repo for nek. Sorry - I thought I had upgraded this in October but apparently had not committed to the repo then. Hopefully all should work -- I retested my original benchmark w/ this new version and it is functioning. Please let me know if this now works for you. You should be able to modify any one of the 12 edges. Paul On Sat, 3 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Were you able to figure out the issue with Markus's midpoint case??? Thank you for looking into this! > > > > Kindly, > > > > Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, March 29, 2010 11:37:43 AM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] Representing Curved Side in any plane > > > Hi Markus, > > Thanks -- I'll check into it. > > Paul > > > On Mon, 29 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> just double-checked, that's what I did. I only ran it for one time step without >> any meaningful physics, though. >> Attached are all case files. The nek version I am using is revision 456. >> >> Markus >> >> >> >> Quoting nek5000-users at lists.mcs.anl.gov: >> >>> >>> Hi Markus, >>> >>> Did you visualize this with VisIt and with the geometry >>> put out into (at least) the first .fld or .f file ? >>> >>> Paul >>> >>> >>> On Mon, 29 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi, >>>> >>>> I was looking into the midpoint feature and generated a cube (1 element, x, >>>> y, z from 0 to 1) in prenek, then converted all edges to the midpoint >>>> notation with prenek, and then manipulated one edge in the rea file. This >>> is >>>> the resulting curved side section: >>>> ??***** CURVED SIDE DATA ***** >>>> ?? ?? ?? ??12 Curved sides follow IEDGE,IEL,CURVE(I),I=1,5, CCURVE >>>> ??1 ??1 ??0.500000 ?? ?? ?? 0.00000 ?? ?? ?? 0.00000 ?? ?? ?? 0.00000 0.00000 ?? ?? m >>>> ??2 ??1 ?? 1.10000 ?? ?? ??0.500000 ?? ?? ?? 0.00000 ?? ?? ?? 0.00000 0.00000 ?? ?? m >>>> . >>>> . >>>> . >>>> 10 ??1 ?? 1.00000 ?? ?? -0.500000 ?? ?? ??0.500000 ?? ?? ?? 0.00000 0.00000 ?? ?? m >>>> 11 ??1 ?? 1.00000 ?? ?? ?? 1.00000 ?? ?? ??0.500000 ?? ?? ?? 0.00000 0.00000 ?? ?? m >>>> 12 ??1 ?? 0.00000 ?? ?? ?? 1.00000 ?? ?? ??0.500000 ?? ?? ?? 0.00000 0.00000 ?? ?? m >>>> >>>> where edge 10 is supposedly not a straight line any more. >>>> >>>> When I run this in nek, however, the cube still comes out with straight >>>> edges. >>>> >>>> Are there any other parameters I need to set? >>>> >>>> I checked out the most recent nek version and overcame compilation issues >>>> with gcc-gfortran 4.4.3-4.fc12 from the fedora 12 repository. >>>> >>>> Thanks, >>>> Markus >>>> >>>> >>>> nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>> >>>>> Michael, >>>>> >>>>> I've only recently added general purpose midside-node support, >>>>> which puts a point in 3-space for any one of the 12 edges and >>>>> nek then fits a parabola to this. >>>>> >>>>> I'll set up an example that demos this. ??The feature has limited >>>>> support at the moment -- but does work in nek5000 and generates >>>>> correct geometry. >>>>> >>>>> Depending on what you are after, there may be other ways to >>>>> generate the geometry. ?? One of my favorite techniques is to >>>>> project a given input geometry onto the desired surface. >>>>> >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>> On Sat, 27 Mar 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>> >>>>> >>>>> ??Hello Users, >>>>> >>>>> >>>>> >>>>> >>>>> ??My question is in regard to the curved side data section in the REA >>>>> file. ??I know that the first 3 terms describe the side, element, and >>>>> radius, but there are several other numbers that are currently zero, and >>>>> then the letter C. >>>>> >>>>> >>>>> >>>>> ??Background for the question: I have a situation where I would like to >>>>> curve an element edge in any plane. I know this is possible from >>>>> previous posts regarding a sphere.rea. >>>>> >>>>> >>>>> >>>>> ??I know that with two points and a radius, that is enough to describe a >>>>> circle in a plane. ??But lets say I have a side where 2 pts lie on the >>>>> XY plane, but the center of the circle is located on the YZ plane for >>>>> example... the question is how to represent this in the REA. In the REA >>>>> you just give the element side ( 2 pts ) and the radius, which does fix >>>>> the circle center but the plane that contains the center is not >>>>> fixed. ??So what I am wondering is what the other numbers in this >>>>> section do...if you could say, give the center instead of the radius, or >>>>> give a third point with the other 2 pts in the element side to fully >>>>> define the circle and plane. >>>>> >>>>> >>>>> >>>>> ??Also, Is it possible to curve the remaining 4 sides of the element >>>>> (edges 9, 10, 11, 12 that would be in the "z" direction) in the same >>>>> manner as edges 1-8? Thanks for any input on this matter! >>>>> >>>>> >>>>> >>>>> ??Regards, >>>>> >>>>> ??Michael Meador >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Apr 5 22:17:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 5 Apr 2010 22:17:21 -0500 (CDT) Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: <2025146810.3567491270523618394.JavaMail.root@neo-mail-3> Message-ID: <711698073.3568971270523841627.JavaMail.root@neo-mail-3> Hey Paul, Sounds great! And I think this is exactly what we needed! We will try it tomorrow. Thanks again, Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, April 5, 2010 9:29:33 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Representing Curved Side in any plane Hi, I've just added the midside-node support to the current svn repo for nek. Sorry - I thought I had upgraded this in October but apparently had not committed to the repo then. Hopefully all should work -- I retested my original benchmark w/ this new version and it is functioning. Please let me know if this now works for you. You should be able to modify any one of the 12 edges. Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 6 05:32:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 06 Apr 2010 12:32:52 +0200 Subject: [Nek5000-users] Question about method & error Message-ID: <1270549972.20672.44.camel@localhost.localdomain> Hello all, Am I correct in understanding that all components of velocity are stored at the same locations (the Gauss?Lobatto?Legendre points), while the pressure is located at the Gauss?Legendre points? This being in contrast to a MAC type staggered grid, where each velocity component resides at different spatial locations. I am just getting started here. Ran all the example cases and am trying to understand the results. I get the following error: VisIt could not read from the file "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". The generated error message was: There was an error opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo When using the following metadata file: NEK5000 version: 1.0 filetemplate: turbChannel0.f%04d firsttimestep: 1 numtimesteps: 1 I get no errors but there seems to be no data to plot, the vector plot for example is greyed out. Trying to plot the mesh results in: The Mesh plot of variable "mesh" yielded no data. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Tue Apr 6 05:45:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 6 Apr 2010 12:45:03 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270549972.20672.44.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> Message-ID: <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> Hi Frank, On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > Am I correct in understanding that all components of velocity are > stored at the same locations (the Gauss?Lobatto?Legendre points), while > the pressure is located at the Gauss?Legendre points? This being in > contrast to a MAC type staggered grid, where each velocity component > resides at different spatial locations. > Yes that's correct! In NEK two different methods are implemented: PN/PN: (v,p) are defined on the GLL points PN/PN-2: v is defined on the GLL points and p on the GL points > VisIt could not read from the file > "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > > The generated error message was: > > There was an error > opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > > When using the following metadata file: > > NEK5000 > version: 1.0 > filetemplate: turbChannel0.f%04d > firsttimestep: 1 > numtimesteps: 1 It seems like you're using a wrong filetemplate. Please try again with: filetemplate: turbChannel%01d.f%04d #Stefan From nek5000-users at lists.mcs.anl.gov Tue Apr 6 05:54:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 06 Apr 2010 12:54:38 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> Message-ID: <1270551278.20672.58.camel@localhost.localdomain> Hello Stefan, Thanks, that fixed it. By the way, (from your earlier email) what does NEK-NEK stand for? Cheers, Frank On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Am I correct in understanding that all components of velocity are > > stored at the same locations (the Gauss?Lobatto?Legendre points), while > > the pressure is located at the Gauss?Legendre points? This being in > > contrast to a MAC type staggered grid, where each velocity component > > resides at different spatial locations. > > > Yes that's correct! In NEK two different methods are implemented: > > PN/PN: (v,p) are defined on the GLL points > PN/PN-2: v is defined on the GLL points and p on the GL points > > > > VisIt could not read from the file > > "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > > > > The generated error message was: > > > > There was an error > > opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > > > > When using the following metadata file: > > > > NEK5000 > > version: 1.0 > > filetemplate: turbChannel0.f%04d > > firsttimestep: 1 > > numtimesteps: 1 > It seems like you're using a wrong filetemplate. Please try again with: > filetemplate: turbChannel%01d.f%04d > > > #Stefan > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Tue Apr 6 05:56:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 6 Apr 2010 12:56:32 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> Message-ID: <7F52A8E0-AAC0-4971-AD48-DF19B32E91C2@lav.mavt.ethz.ch> One striking property of the implemented PN/PN method is that convergence is ensured for all pairs of approximation spaces. In other words, these spaces do not need be compatible, i.e. they do not need satisfy the LBB condition. This is in contrast to the implemented PN/PN-2 method. Only compatible spaces for u and p are free of spurious modes. hth, Stefan On Apr 6, 2010, at 12:45 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: >> Am I correct in understanding that all components of velocity are >> stored at the same locations (the Gauss?Lobatto?Legendre points), while >> the pressure is located at the Gauss?Legendre points? This being in >> contrast to a MAC type staggered grid, where each velocity component >> resides at different spatial locations. >> > Yes that's correct! In NEK two different methods are implemented: > > PN/PN: (v,p) are defined on the GLL points > PN/PN-2: v is defined on the GLL points and p on the GL points > > >> VisIt could not read from the file >> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". >> >> The generated error message was: >> >> There was an error >> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo >> >> When using the following metadata file: >> >> NEK5000 >> version: 1.0 >> filetemplate: turbChannel0.f%04d >> firsttimestep: 1 >> numtimesteps: 1 > It seems like you're using a wrong filetemplate. Please try again with: > filetemplate: turbChannel%01d.f%04d > > > #Stefan > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Apr 6 05:58:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 6 Apr 2010 12:58:50 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270551278.20672.58.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> Message-ID: <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. Stefan On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Stefan, > > Thanks, that fixed it. By the way, (from your earlier email) what does > NEK-NEK stand for? > > Cheers, > Frank > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Frank, >> >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> Am I correct in understanding that all components of velocity are >>> stored at the same locations (the Gauss?Lobatto?Legendre points), while >>> the pressure is located at the Gauss?Legendre points? This being in >>> contrast to a MAC type staggered grid, where each velocity component >>> resides at different spatial locations. >>> >> Yes that's correct! In NEK two different methods are implemented: >> >> PN/PN: (v,p) are defined on the GLL points >> PN/PN-2: v is defined on the GLL points and p on the GL points >> >> >>> VisIt could not read from the file >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". >>> >>> The generated error message was: >>> >>> There was an error >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo >>> >>> When using the following metadata file: >>> >>> NEK5000 >>> version: 1.0 >>> filetemplate: turbChannel0.f%04d >>> firsttimestep: 1 >>> numtimesteps: 1 >> It seems like you're using a wrong filetemplate. Please try again with: >> filetemplate: turbChannel%01d.f%04d >> >> >> #Stefan >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Apr 6 06:01:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 06 Apr 2010 13:01:44 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> Message-ID: <1270551705.20672.63.camel@localhost.localdomain> On Tue, 2010-04-06 at 12:58 +0200, nek5000-users at lists.mcs.anl.gov wrote: > NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. I am very interested in this. By the way, I am an experienced Fortran and MPI programmer. Cheers, Frank > > Stefan > > > On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello Stefan, > > > > Thanks, that fixed it. By the way, (from your earlier email) what does > > NEK-NEK stand for? > > > > Cheers, > > Frank > > > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Frank, > >> > >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>> Am I correct in understanding that all components of velocity are > >>> stored at the same locations (the Gauss?Lobatto?Legendre points), while > >>> the pressure is located at the Gauss?Legendre points? This being in > >>> contrast to a MAC type staggered grid, where each velocity component > >>> resides at different spatial locations. > >>> > >> Yes that's correct! In NEK two different methods are implemented: > >> > >> PN/PN: (v,p) are defined on the GLL points > >> PN/PN-2: v is defined on the GLL points and p on the GL points > >> > >> > >>> VisIt could not read from the file > >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > >>> > >>> The generated error message was: > >>> > >>> There was an error > >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > >>> > >>> When using the following metadata file: > >>> > >>> NEK5000 > >>> version: 1.0 > >>> filetemplate: turbChannel0.f%04d > >>> firsttimestep: 1 > >>> numtimesteps: 1 > >> It seems like you're using a wrong filetemplate. Please try again with: > >> filetemplate: turbChannel%01d.f%04d > >> > >> > >> #Stefan > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Tue Apr 6 06:46:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 06 Apr 2010 13:46:15 +0200 Subject: [Nek5000-users] Marangoni effect Message-ID: <1270554376.20672.73.camel@localhost.localdomain> Hello all, Is there a boundary condition that allows one to specify the shear stress vector in terms of the temperature gradient along the boundary? The boundary in question is a curved surface in 3D. If not, do y'all think that is this something that could be done without extreme difficulty? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Tue Apr 6 06:58:40 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 6 Apr 2010 06:58:40 -0500 (CDT) Subject: [Nek5000-users] Marangoni effect In-Reply-To: <1270554376.20672.73.camel@localhost.localdomain> References: <1270554376.20672.73.camel@localhost.localdomain> Message-ID: Hi Frank, There should be a way to impose the shear, which corresponds to an inhomogeneous Neumann condition in the stress-formulation. The precise values would be supplied by the user through userbc -- generally it's a good idea to compute the quantity in userchk and save this to an array, then de-reference the array values in userbc(), which is called once per gridpoint per timestep (as opposed to once per timestep, like userchk). I'll check to see if I can determine the correct bc flag to enable this condition. To be sure, you will need to use the Pn-Pn-2 formulation, with the stress condition turned on. Unit normal and unit tangent vectors are available for each element surface, and routines that allow computations with volume-based and surface-based arrays abound (e.g., compute dot-product of grad T with unit normal, where former array is volume-based and latter is surface based). Note that Nek supporst an ALE free-surface formulation - just fyi if this is relevant to your problem. Paul On Tue, 6 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, Is there a boundary condition that allows one to specify the shear stress vector in terms of the temperature gradient along the boundary? The boundary in question is a curved surface in 3D. If not, do y'all think that is this something that could be done without extreme difficulty? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit??t Wien (Technical University of Vienna) Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Apr 6 15:53:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 06 Apr 2010 22:53:54 +0200 Subject: [Nek5000-users] Marangoni effect In-Reply-To: References: <1270554376.20672.73.camel@localhost.localdomain> Message-ID: <1270587235.3302.82.camel@localhost.localdomain> Hello Paul, Thanks for the help here. I am currently trying to run some test cases, specifically the one "turbChannel". I am getting errors: WARNING: DIV(V)-QTL too large! The ALE free-surface formulation is something that we are very interested using in the next step of our modeling. Cheers, Frank On Tue, 2010-04-06 at 06:58 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > There should be a way to impose the shear, which corresponds to an > inhomogeneous Neumann condition in the stress-formulation. > > The precise values would be supplied by the user through userbc -- > generally it's a good idea to compute the quantity in userchk and > save this to an array, then de-reference the array values in userbc(), > which is called once per gridpoint per timestep (as opposed to > once per timestep, like userchk). > > I'll check to see if I can determine the correct bc flag to enable > this condition. To be sure, you will need to use the Pn-Pn-2 > formulation, with the stress condition turned on. > > Unit normal and unit tangent vectors are available for each element > surface, and routines that allow computations with volume-based and > surface-based arrays abound (e.g., compute dot-product of grad T with > unit normal, where former array is volume-based and latter is surface > based). > > > > Note that Nek supporst an ALE free-surface formulation - just fyi > if this is relevant to your problem. > > Paul > > > On Tue, 6 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > Is there a boundary condition that allows one to specify the shear > stress vector in terms of the temperature gradient along the boundary? > The boundary in question is a curved surface in 3D. > > If not, do y'all think that is this something that could be done without > extreme difficulty? > > Cheers, > Frank > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 7 04:27:28 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 07 Apr 2010 11:27:28 +0200 Subject: [Nek5000-users] visualization - tecplot Message-ID: <1270632448.5481.20.camel@localhost.localdomain> Hello all, Does anyone know of any way to get the output files into a format that Tecplot understands? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 7 04:40:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 11:40:46 +0200 Subject: [Nek5000-users] visualization - tecplot In-Reply-To: <1270632448.5481.20.camel@localhost.localdomain> References: <1270632448.5481.20.camel@localhost.localdomain> Message-ID: No, we have our own data layout in NEK. However there are some nek2tec converters around but I am not convinced that this is the way to go. You can also use VisIt to export your data into a Tecplot compatible format. hth, Stefan On Apr 7, 2010, at 11:27 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > Does anyone know of any way to get the output files into a format that > Tecplot understands? > > Cheers, > Frank > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 7 05:21:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 07 Apr 2010 12:21:34 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: <7F52A8E0-AAC0-4971-AD48-DF19B32E91C2@lav.mavt.ethz.ch> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <7F52A8E0-AAC0-4971-AD48-DF19B32E91C2@lav.mavt.ethz.ch> Message-ID: <1270635694.8715.3.camel@localhost.localdomain> Hello Stefan, Couple of questions. If using the PN/PN-2 method, are the variables written out at the PN or PN-2 nodes? Also, are the passive scalars stored at the PN nodes? In the PN/PN method, is some filtering done to remove the spurious modes from the pressure field? By the way, are you in Europe? Cheers, Frank On Tue, 2010-04-06 at 12:56 +0200, nek5000-users at lists.mcs.anl.gov wrote: > One striking property of the implemented PN/PN method is that convergence > is ensured for all pairs of approximation spaces. In other words, these spaces do not need be compatible, i.e. they do not need satisfy the LBB condition. > > This is in contrast to the implemented PN/PN-2 method. Only compatible spaces for u and p are free of spurious modes. > > hth, > Stefan > > > On Apr 6, 2010, at 12:45 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Frank, > > > > On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Am I correct in understanding that all components of velocity are > >> stored at the same locations (the Gauss?Lobatto?Legendre points), while > >> the pressure is located at the Gauss?Legendre points? This being in > >> contrast to a MAC type staggered grid, where each velocity component > >> resides at different spatial locations. > >> > > Yes that's correct! In NEK two different methods are implemented: > > > > PN/PN: (v,p) are defined on the GLL points > > PN/PN-2: v is defined on the GLL points and p on the GL points > > > > > >> VisIt could not read from the file > >> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > >> > >> The generated error message was: > >> > >> There was an error > >> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > >> > >> When using the following metadata file: > >> > >> NEK5000 > >> version: 1.0 > >> filetemplate: turbChannel0.f%04d > >> firsttimestep: 1 > >> numtimesteps: 1 > > It seems like you're using a wrong filetemplate. Please try again with: > > filetemplate: turbChannel%01d.f%04d > > > > > > #Stefan > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 7 05:35:10 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 12:35:10 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270635694.8715.3.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <7F52A8E0-AAC0-4971-AD48-DF19B32E91C2@lav.mavt.ethz.ch> <1270635694.8715.3.camel@localhost.localdomain> Message-ID: <4842ADF1-6E7F-49BF-92E2-12CCCEFDE753@lav.mavt.ethz.ch> Hi Frank, > Couple of questions. If using the PN/PN-2 method, are the variables > written out at the PN or PN-2 nodes? We dump the data using the GLL points. For visualization there is also an option to dump the data on a regular (uniform) mesh. > Also, are the passive scalars stored at the PN nodes? Yes on the GLL nodes. > In the PN/PN method, is some filtering done to remove the spurious modes > from the pressure field? No, there is no filtering needed because the method is free of spurious modes. > By the way, are you in Europe? Yes, but I'll move to the US soon. Stefan From nek5000-users at lists.mcs.anl.gov Wed Apr 7 06:10:02 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 07 Apr 2010 13:10:02 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> Message-ID: <1270638602.8715.21.camel@localhost.localdomain> On Tue, 2010-04-06 at 12:58 +0200, nek5000-users at lists.mcs.anl.gov wrote: > NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. Hello Stefan, If I can make up a grid, is getting an instance of the NEK-NEK capability working something you are willing to work with me to get running? Couple of questions: How experimental is the NEK-NEK capability? And is there a specific application or class of problems driving it? Cheers, Frank > > Stefan > > > On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello Stefan, > > > > Thanks, that fixed it. By the way, (from your earlier email) what does > > NEK-NEK stand for? > > > > Cheers, > > Frank > > > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Frank, > >> > >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>> Am I correct in understanding that all components of velocity are > >>> stored at the same locations (the Gauss?Lobatto?Legendre points), while > >>> the pressure is located at the Gauss?Legendre points? This being in > >>> contrast to a MAC type staggered grid, where each velocity component > >>> resides at different spatial locations. > >>> > >> Yes that's correct! In NEK two different methods are implemented: > >> > >> PN/PN: (v,p) are defined on the GLL points > >> PN/PN-2: v is defined on the GLL points and p on the GL points > >> > >> > >>> VisIt could not read from the file > >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > >>> > >>> The generated error message was: > >>> > >>> There was an error > >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > >>> > >>> When using the following metadata file: > >>> > >>> NEK5000 > >>> version: 1.0 > >>> filetemplate: turbChannel0.f%04d > >>> firsttimestep: 1 > >>> numtimesteps: 1 > >> It seems like you're using a wrong filetemplate. Please try again with: > >> filetemplate: turbChannel%01d.f%04d > >> > >> > >> #Stefan > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 7 06:21:22 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 06:21:22 -0500 (CDT) Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270638602.8715.21.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> Message-ID: Hi Frank, There are several apps driving it. At present, I think that the version is slightly out of step w/ our current repo - but not far. The original developer has moved on to a university and to other projects, so has not been pushing it since September (though I used it extensively in January for some tests). I've been holding off on pushing it further till I had more support. If your shared interface has elements on either side that are conforming it might also be possible to study the Marangoni problem in the std. nek if you use the ALE formulation --- If you use a fixed interface we would suffer from the fact that the pressure would have a nullspace of dimension 2 since pressure on either side of the (rigid) interface would be determined up to a constant. This would be difficult for our solvers given that we've designed them only to handle the case of an at-most one-dimensional nullspace. How complex is your domain? Paul On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > On Tue, 2010-04-06 at 12:58 +0200, nek5000-users at lists.mcs.anl.gov wrote: > NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. Hello Stefan, If I can make up a grid, is getting an instance of the NEK-NEK capability working something you are willing to work with me to get running? Couple of questions: How experimental is the NEK-NEK capability? And is there a specific application or class of problems driving it? Cheers, Frank > > Stefan > > > On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello Stefan, > > > > Thanks, that fixed it. By the way, (from your earlier email) what does > > NEK-NEK stand for? > > > > Cheers, > > Frank > > > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Frank, > >> > >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>> Am I correct in understanding that all components of velocity are > >>> stored at the same locations (the Gauss???Lobatto???Legendre points), while > >>> the pressure is located at the Gauss???Legendre points? This being in > >>> contrast to a MAC type staggered grid, where each velocity component > >>> resides at different spatial locations. > >>> > >> Yes that's correct! In NEK two different methods are implemented: > >> > >> PN/PN: (v,p) are defined on the GLL points > >> PN/PN-2: v is defined on the GLL points and p on the GL points > >> > >> > >>> VisIt could not read from the file > >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > >>> > >>> The generated error message was: > >>> > >>> There was an error > >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > >>> > >>> When using the following metadata file: > >>> > >>> NEK5000 > >>> version: 1.0 > >>> filetemplate: turbChannel0.f%04d > >>> firsttimestep: 1 > >>> numtimesteps: 1 > >> It seems like you're using a wrong filetemplate. Please try again with: > >> filetemplate: turbChannel%01d.f%04d > >> > >> > >> #Stefan > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit??t Wien (Technical University of Vienna) > > Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit??t Wien (Technical University of Vienna) Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 7 06:52:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 07 Apr 2010 13:52:41 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> Message-ID: <1270641161.8715.36.camel@localhost.localdomain> On Wed, 2010-04-07 at 06:21 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > There are several apps driving it. At present, I think that the > version is slightly out of step w/ our current repo - but not far. > The original developer has moved on to a university and to other > projects, so has not been pushing it since September (though I used > it extensively in January for some tests). I've been holding off > on pushing it further till I had more support. > > If your shared interface has elements on either side that are > conforming it might also be possible to study the Marangoni > problem in the std. nek if you use the ALE formulation --- > If you use a fixed interface we would suffer from the fact > that the pressure would have a nullspace of dimension 2 > since pressure on either side of the (rigid) interface > would be determined up to a constant. This would be > difficult for our solvers given that we've designed them > only to handle the case of an at-most one-dimensional nullspace. Hi Paul, The elements on both sides of the interface are conforming. If the interface was free to move, but had a very high surface tension, high enough that it was essentially fixed, then perhaps that could work? But then there could be problems with ill-conditioning with a very high surface tension. > > How complex is your domain? Not very. It consists of a liquid suspended (due to surface tension) between two metal posts. The liquid is surrounded by a gas flow. http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/schematic-3d-liquid-bridge-2.png I have gridded it using a block structured grid of 9 blocks, five in the liquid region and four in the gas. The terminology for the whole problem is a "liquid bridge". Cheers, Frank > > Paul > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > On Tue, 2010-04-06 at 12:58 +0200, nek5000-users at lists.mcs.anl.gov > wrote: > > NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. > > Hello Stefan, > > If I can make up a grid, is getting an instance of the NEK-NEK > capability working something you are willing to work with me to get > running? Couple of questions: How experimental is the NEK-NEK > capability? And is there a specific application or class of problems > driving it? > > Cheers, > Frank > > > > > Stefan > > > > > > On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Hello Stefan, > > > > > > Thanks, that fixed it. By the way, (from your earlier email) what does > > > NEK-NEK stand for? > > > > > > Cheers, > > > Frank > > > > > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > > > wrote: > > >> Hi Frank, > > >> > > >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > > >>> Am I correct in understanding that all components of velocity are > > >>> stored at the same locations (the Gauss?Lobatto?Legendre points), while > > >>> the pressure is located at the Gauss?Legendre points? This being in > > >>> contrast to a MAC type staggered grid, where each velocity component > > >>> resides at different spatial locations. > > >>> > > >> Yes that's correct! In NEK two different methods are implemented: > > >> > > >> PN/PN: (v,p) are defined on the GLL points > > >> PN/PN-2: v is defined on the GLL points and p on the GL points > > >> > > >> > > >>> VisIt could not read from the file > > >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > > >>> > > >>> The generated error message was: > > >>> > > >>> There was an error > > >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > > >>> > > >>> When using the following metadata file: > > >>> > > >>> NEK5000 > > >>> version: 1.0 > > >>> filetemplate: turbChannel0.f%04d > > >>> firsttimestep: 1 > > >>> numtimesteps: 1 > > >> It seems like you're using a wrong filetemplate. Please try again with: > > >> filetemplate: turbChannel%01d.f%04d > > >> > > >> > > >> #Stefan > > >> > > >> _______________________________________________ > > >> Nek5000-users mailing list > > >> Nek5000-users at lists.mcs.anl.gov > > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -- > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > Technische Universit?t Wien (Technical University of Vienna) > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > > Mechanics and Heat Transfer) > > > Resselgasse 3 > > > 1040 Wien > > > Tel: +4315880132232 > > > Fax: +4315880132299 > > > Cell:+436765203470 > > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > _______________________________________________ > > > Nek5000-users mailing list > > > Nek5000-users at lists.mcs.anl.gov > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 7 08:45:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 08:45:54 -0500 (CDT) Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270641161.8715.36.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> Message-ID: Hi Frank, I think the best way to proceed would be to define an interior interface and not to use the nek-nek coupling. (This is a judgement call based on the current state of the codes.) The pressure shouldn't be much of an issue in this case -- as long as there is a bit of flexibility then the dimension of the null space is 1 (or in your case, with outflow bcs, 0). Let me look into this a bit... Paul On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > On Wed, 2010-04-07 at 06:21 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > There are several apps driving it. At present, I think that the > version is slightly out of step w/ our current repo - but not far. > The original developer has moved on to a university and to other > projects, so has not been pushing it since September (though I used > it extensively in January for some tests). I've been holding off > on pushing it further till I had more support. > > If your shared interface has elements on either side that are > conforming it might also be possible to study the Marangoni > problem in the std. nek if you use the ALE formulation --- > If you use a fixed interface we would suffer from the fact > that the pressure would have a nullspace of dimension 2 > since pressure on either side of the (rigid) interface > would be determined up to a constant. This would be > difficult for our solvers given that we've designed them > only to handle the case of an at-most one-dimensional nullspace. Hi Paul, The elements on both sides of the interface are conforming. If the interface was free to move, but had a very high surface tension, high enough that it was essentially fixed, then perhaps that could work? But then there could be problems with ill-conditioning with a very high surface tension. > > How complex is your domain? Not very. It consists of a liquid suspended (due to surface tension) between two metal posts. The liquid is surrounded by a gas flow. http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/schematic-3d-liquid-bridge-2.png I have gridded it using a block structured grid of 9 blocks, five in the liquid region and four in the gas. The terminology for the whole problem is a "liquid bridge". Cheers, Frank > > Paul > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > On Tue, 2010-04-06 at 12:58 +0200, nek5000-users at lists.mcs.anl.gov > wrote: > > NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. > > Hello Stefan, > > If I can make up a grid, is getting an instance of the NEK-NEK > capability working something you are willing to work with me to get > running? Couple of questions: How experimental is the NEK-NEK > capability? And is there a specific application or class of problems > driving it? > > Cheers, > Frank > > > > > Stefan > > > > > > On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Hello Stefan, > > > > > > Thanks, that fixed it. By the way, (from your earlier email) what does > > > NEK-NEK stand for? > > > > > > Cheers, > > > Frank > > > > > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > > > wrote: > > >> Hi Frank, > > >> > > >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > > >>> Am I correct in understanding that all components of velocity are > > >>> stored at the same locations (the Gauss???Lobatto???Legendre points), while > > >>> the pressure is located at the Gauss???Legendre points? This being in > > >>> contrast to a MAC type staggered grid, where each velocity component > > >>> resides at different spatial locations. > > >>> > > >> Yes that's correct! In NEK two different methods are implemented: > > >> > > >> PN/PN: (v,p) are defined on the GLL points > > >> PN/PN-2: v is defined on the GLL points and p on the GL points > > >> > > >> > > >>> VisIt could not read from the file > > >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > > >>> > > >>> The generated error message was: > > >>> > > >>> There was an error > > >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > > >>> > > >>> When using the following metadata file: > > >>> > > >>> NEK5000 > > >>> version: 1.0 > > >>> filetemplate: turbChannel0.f%04d > > >>> firsttimestep: 1 > > >>> numtimesteps: 1 > > >> It seems like you're using a wrong filetemplate. Please try again with: > > >> filetemplate: turbChannel%01d.f%04d > > >> > > >> > > >> #Stefan > > >> > > >> _______________________________________________ > > >> Nek5000-users mailing list > > >> Nek5000-users at lists.mcs.anl.gov > > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -- > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > Technische Universit??t Wien (Technical University of Vienna) > > > Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid > > > Mechanics and Heat Transfer) > > > Resselgasse 3 > > > 1040 Wien > > > Tel: +4315880132232 > > > Fax: +4315880132299 > > > Cell:+436765203470 > > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > _______________________________________________ > > > Nek5000-users mailing list > > > Nek5000-users at lists.mcs.anl.gov > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit??t Wien (Technical University of Vienna) > Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit??t Wien (Technical University of Vienna) Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 7 08:52:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 08:52:15 -0500 (CDT) Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270641161.8715.36.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> Message-ID: Frank, Do you know the surface tension for your case? Is it a function of temperature? Paul On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > On Wed, 2010-04-07 at 06:21 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > There are several apps driving it. At present, I think that the > version is slightly out of step w/ our current repo - but not far. > The original developer has moved on to a university and to other > projects, so has not been pushing it since September (though I used > it extensively in January for some tests). I've been holding off > on pushing it further till I had more support. > > If your shared interface has elements on either side that are > conforming it might also be possible to study the Marangoni > problem in the std. nek if you use the ALE formulation --- > If you use a fixed interface we would suffer from the fact > that the pressure would have a nullspace of dimension 2 > since pressure on either side of the (rigid) interface > would be determined up to a constant. This would be > difficult for our solvers given that we've designed them > only to handle the case of an at-most one-dimensional nullspace. Hi Paul, The elements on both sides of the interface are conforming. If the interface was free to move, but had a very high surface tension, high enough that it was essentially fixed, then perhaps that could work? But then there could be problems with ill-conditioning with a very high surface tension. > > How complex is your domain? Not very. It consists of a liquid suspended (due to surface tension) between two metal posts. The liquid is surrounded by a gas flow. http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/schematic-3d-liquid-bridge-2.png I have gridded it using a block structured grid of 9 blocks, five in the liquid region and four in the gas. The terminology for the whole problem is a "liquid bridge". Cheers, Frank > > Paul > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > On Tue, 2010-04-06 at 12:58 +0200, nek5000-users at lists.mcs.anl.gov > wrote: > > NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. > > Hello Stefan, > > If I can make up a grid, is getting an instance of the NEK-NEK > capability working something you are willing to work with me to get > running? Couple of questions: How experimental is the NEK-NEK > capability? And is there a specific application or class of problems > driving it? > > Cheers, > Frank > > > > > Stefan > > > > > > On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Hello Stefan, > > > > > > Thanks, that fixed it. By the way, (from your earlier email) what does > > > NEK-NEK stand for? > > > > > > Cheers, > > > Frank > > > > > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > > > wrote: > > >> Hi Frank, > > >> > > >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > > >>> Am I correct in understanding that all components of velocity are > > >>> stored at the same locations (the Gauss?Lobatto?Legendre points), while > > >>> the pressure is located at the Gauss?Legendre points? This being in > > >>> contrast to a MAC type staggered grid, where each velocity component > > >>> resides at different spatial locations. > > >>> > > >> Yes that's correct! In NEK two different methods are implemented: > > >> > > >> PN/PN: (v,p) are defined on the GLL points > > >> PN/PN-2: v is defined on the GLL points and p on the GL points > > >> > > >> > > >>> VisIt could not read from the file > > >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > > >>> > > >>> The generated error message was: > > >>> > > >>> There was an error > > >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > > >>> > > >>> When using the following metadata file: > > >>> > > >>> NEK5000 > > >>> version: 1.0 > > >>> filetemplate: turbChannel0.f%04d > > >>> firsttimestep: 1 > > >>> numtimesteps: 1 > > >> It seems like you're using a wrong filetemplate. Please try again with: > > >> filetemplate: turbChannel%01d.f%04d > > >> > > >> > > >> #Stefan > > >> > > >> _______________________________________________ > > >> Nek5000-users mailing list > > >> Nek5000-users at lists.mcs.anl.gov > > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -- > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > Technische Universit?t Wien (Technical University of Vienna) > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > > Mechanics and Heat Transfer) > > > Resselgasse 3 > > > 1040 Wien > > > Tel: +4315880132232 > > > Fax: +4315880132299 > > > Cell:+436765203470 > > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > _______________________________________________ > > > Nek5000-users mailing list > > > Nek5000-users at lists.mcs.anl.gov > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 7 09:24:19 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 07 Apr 2010 16:24:19 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> Message-ID: <1270650259.8715.44.camel@localhost.localdomain> On Wed, 2010-04-07 at 08:52 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > Do you know the surface tension for your case? Is it a function > of temperature? Hi Paul, The surface tension depends linearly on the temperature, therefore the shear stress (tangential to the interface) depends linearly on the temperature gradient along (tangential to) the interface. Cheers, Frank > > Paul > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > On Wed, 2010-04-07 at 06:21 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Frank, > > > > There are several apps driving it. At present, I think that the > > version is slightly out of step w/ our current repo - but not far. > > The original developer has moved on to a university and to other > > projects, so has not been pushing it since September (though I used > > it extensively in January for some tests). I've been holding off > > on pushing it further till I had more support. > > > > If your shared interface has elements on either side that are > > conforming it might also be possible to study the Marangoni > > problem in the std. nek if you use the ALE formulation --- > > If you use a fixed interface we would suffer from the fact > > that the pressure would have a nullspace of dimension 2 > > since pressure on either side of the (rigid) interface > > would be determined up to a constant. This would be > > difficult for our solvers given that we've designed them > > only to handle the case of an at-most one-dimensional nullspace. > > Hi Paul, > > The elements on both sides of the interface are conforming. If the > interface was free to move, but had a very high surface tension, high > enough that it was essentially fixed, then perhaps that could work? But > then there could be problems with ill-conditioning with a very high > surface tension. > > > > > How complex is your domain? > > Not very. It consists of a liquid suspended (due to surface tension) > between two metal posts. The liquid is surrounded by a gas flow. > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/schematic-3d-liquid-bridge-2.png > > I have gridded it using a block structured grid of 9 blocks, five in the > liquid region and four in the gas. The terminology for the whole problem > is a "liquid bridge". > > Cheers, > Frank > > > > > Paul > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > On Tue, 2010-04-06 at 12:58 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > > > NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. > > > > Hello Stefan, > > > > If I can make up a grid, is getting an instance of the NEK-NEK > > capability working something you are willing to work with me to get > > running? Couple of questions: How experimental is the NEK-NEK > > capability? And is there a specific application or class of problems > > driving it? > > > > Cheers, > > Frank > > > > > > > > Stefan > > > > > > > > > On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > Hello Stefan, > > > > > > > > Thanks, that fixed it. By the way, (from your earlier email) what does > > > > NEK-NEK stand for? > > > > > > > > Cheers, > > > > Frank > > > > > > > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > > > > wrote: > > > >> Hi Frank, > > > >> > > > >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > >>> Am I correct in understanding that all components of velocity are > > > >>> stored at the same locations (the Gauss?Lobatto?Legendre points), while > > > >>> the pressure is located at the Gauss?Legendre points? This being in > > > >>> contrast to a MAC type staggered grid, where each velocity component > > > >>> resides at different spatial locations. > > > >>> > > > >> Yes that's correct! In NEK two different methods are implemented: > > > >> > > > >> PN/PN: (v,p) are defined on the GLL points > > > >> PN/PN-2: v is defined on the GLL points and p on the GL points > > > >> > > > >> > > > >>> VisIt could not read from the file > > > >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > > > >>> > > > >>> The generated error message was: > > > >>> > > > >>> There was an error > > > >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > > > >>> > > > >>> When using the following metadata file: > > > >>> > > > >>> NEK5000 > > > >>> version: 1.0 > > > >>> filetemplate: turbChannel0.f%04d > > > >>> firsttimestep: 1 > > > >>> numtimesteps: 1 > > > >> It seems like you're using a wrong filetemplate. Please try again with: > > > >> filetemplate: turbChannel%01d.f%04d > > > >> > > > >> > > > >> #Stefan > > > >> > > > >> _______________________________________________ > > > >> Nek5000-users mailing list > > > >> Nek5000-users at lists.mcs.anl.gov > > > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > -- > > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > > Technische Universit?t Wien (Technical University of Vienna) > > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > > > Mechanics and Heat Transfer) > > > > Resselgasse 3 > > > > 1040 Wien > > > > Tel: +4315880132232 > > > > Fax: +4315880132299 > > > > Cell:+436765203470 > > > > fmuldoo (skype) > > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > > > _______________________________________________ > > > > Nek5000-users mailing list > > > > Nek5000-users at lists.mcs.anl.gov > > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > > > _______________________________________________ > > > Nek5000-users mailing list > > > Nek5000-users at lists.mcs.anl.gov > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 7 09:32:08 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 09:32:08 -0500 (CDT) Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270650259.8715.44.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> Message-ID: I think we can do this problem... There is support for an internal interface (set up originally by Lee Ho) and it appears to still be functioning properly. You simply specify sigma as desired, in the userbc routine. At the liquid interface you need to specify a boundary condition "msi" --- moving surface, interior. That is a bit tricky - requires editing the .rea file at present - but not really too difficult. Let me look a bit further. Paul On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > On Wed, 2010-04-07 at 08:52 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > Do you know the surface tension for your case? Is it a function > of temperature? Hi Paul, The surface tension depends linearly on the temperature, therefore the shear stress (tangential to the interface) depends linearly on the temperature gradient along (tangential to) the interface. Cheers, Frank > > Paul > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > On Wed, 2010-04-07 at 06:21 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Frank, > > > > There are several apps driving it. At present, I think that the > > version is slightly out of step w/ our current repo - but not far. > > The original developer has moved on to a university and to other > > projects, so has not been pushing it since September (though I used > > it extensively in January for some tests). I've been holding off > > on pushing it further till I had more support. > > > > If your shared interface has elements on either side that are > > conforming it might also be possible to study the Marangoni > > problem in the std. nek if you use the ALE formulation --- > > If you use a fixed interface we would suffer from the fact > > that the pressure would have a nullspace of dimension 2 > > since pressure on either side of the (rigid) interface > > would be determined up to a constant. This would be > > difficult for our solvers given that we've designed them > > only to handle the case of an at-most one-dimensional nullspace. > > Hi Paul, > > The elements on both sides of the interface are conforming. If the > interface was free to move, but had a very high surface tension, high > enough that it was essentially fixed, then perhaps that could work? But > then there could be problems with ill-conditioning with a very high > surface tension. > > > > > How complex is your domain? > > Not very. It consists of a liquid suspended (due to surface tension) > between two metal posts. The liquid is surrounded by a gas flow. > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/schematic-3d-liquid-bridge-2.png > > I have gridded it using a block structured grid of 9 blocks, five in the > liquid region and four in the gas. The terminology for the whole problem > is a "liquid bridge". > > Cheers, > Frank > > > > > Paul > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > On Tue, 2010-04-06 at 12:58 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > > > NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. > > > > Hello Stefan, > > > > If I can make up a grid, is getting an instance of the NEK-NEK > > capability working something you are willing to work with me to get > > running? Couple of questions: How experimental is the NEK-NEK > > capability? And is there a specific application or class of problems > > driving it? > > > > Cheers, > > Frank > > > > > > > > Stefan > > > > > > > > > On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > Hello Stefan, > > > > > > > > Thanks, that fixed it. By the way, (from your earlier email) what does > > > > NEK-NEK stand for? > > > > > > > > Cheers, > > > > Frank > > > > > > > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > > > > wrote: > > > >> Hi Frank, > > > >> > > > >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > >>> Am I correct in understanding that all components of velocity are > > > >>> stored at the same locations (the Gauss???Lobatto???Legendre points), while > > > >>> the pressure is located at the Gauss???Legendre points? This being in > > > >>> contrast to a MAC type staggered grid, where each velocity component > > > >>> resides at different spatial locations. > > > >>> > > > >> Yes that's correct! In NEK two different methods are implemented: > > > >> > > > >> PN/PN: (v,p) are defined on the GLL points > > > >> PN/PN-2: v is defined on the GLL points and p on the GL points > > > >> > > > >> > > > >>> VisIt could not read from the file > > > >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > > > >>> > > > >>> The generated error message was: > > > >>> > > > >>> There was an error > > > >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > > > >>> > > > >>> When using the following metadata file: > > > >>> > > > >>> NEK5000 > > > >>> version: 1.0 > > > >>> filetemplate: turbChannel0.f%04d > > > >>> firsttimestep: 1 > > > >>> numtimesteps: 1 > > > >> It seems like you're using a wrong filetemplate. Please try again with: > > > >> filetemplate: turbChannel%01d.f%04d > > > >> > > > >> > > > >> #Stefan > > > >> > > > >> _______________________________________________ > > > >> Nek5000-users mailing list > > > >> Nek5000-users at lists.mcs.anl.gov > > > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > -- > > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > > Technische Universit??t Wien (Technical University of Vienna) > > > > Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid > > > > Mechanics and Heat Transfer) > > > > Resselgasse 3 > > > > 1040 Wien > > > > Tel: +4315880132232 > > > > Fax: +4315880132299 > > > > Cell:+436765203470 > > > > fmuldoo (skype) > > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > > > _______________________________________________ > > > > Nek5000-users mailing list > > > > Nek5000-users at lists.mcs.anl.gov > > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > > > _______________________________________________ > > > Nek5000-users mailing list > > > Nek5000-users at lists.mcs.anl.gov > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit??t Wien (Technical University of Vienna) > > Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit??t Wien (Technical University of Vienna) > Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit??t Wien (Technical University of Vienna) Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 7 09:43:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 07 Apr 2010 16:43:32 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> Message-ID: <1270651412.8715.54.camel@localhost.localdomain> On Wed, 2010-04-07 at 09:32 -0500, nek5000-users at lists.mcs.anl.gov wrote: > I think we can do this problem... There is support for an internal > interface (set up originally by Lee Ho) and it appears to still > be functioning properly. > > You simply specify sigma as desired, in the userbc routine. > > At the liquid interface you need to specify a boundary condition > "msi" --- moving surface, interior. > > That is a bit tricky - requires editing the .rea file at present - > but not really too difficult. > > Let me look a bit further. Paul, Great to hear that. Question; an internal interface has the meaning of an internal boundary condition at which velocity and temperature, but not pressure, boundary conditions can be set? Since the normal velocity at the interface is set to zero and the interface completely separates the two fluids, the absolute value of the pressure in the two fluids is independent in the model I have in mind. To put in other words, no pressure gradients across the interface exist in the model. But I guess that will always be the case in the spectral element method, as long as the interface is not inside an element. Cheers, Frank > > Paul > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > On Wed, 2010-04-07 at 08:52 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Frank, > > > > Do you know the surface tension for your case? Is it a function > > of temperature? > > Hi Paul, > > The surface tension depends linearly on the temperature, therefore the > shear stress (tangential to the interface) depends linearly on the > temperature gradient along (tangential to) the interface. > > Cheers, > Frank > > > > > Paul > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > On Wed, 2010-04-07 at 06:21 -0500, nek5000-users at lists.mcs.anl.gov > > wrote: > > > Hi Frank, > > > > > > There are several apps driving it. At present, I think that the > > > version is slightly out of step w/ our current repo - but not far. > > > The original developer has moved on to a university and to other > > > projects, so has not been pushing it since September (though I used > > > it extensively in January for some tests). I've been holding off > > > on pushing it further till I had more support. > > > > > > If your shared interface has elements on either side that are > > > conforming it might also be possible to study the Marangoni > > > problem in the std. nek if you use the ALE formulation --- > > > If you use a fixed interface we would suffer from the fact > > > that the pressure would have a nullspace of dimension 2 > > > since pressure on either side of the (rigid) interface > > > would be determined up to a constant. This would be > > > difficult for our solvers given that we've designed them > > > only to handle the case of an at-most one-dimensional nullspace. > > > > Hi Paul, > > > > The elements on both sides of the interface are conforming. If the > > interface was free to move, but had a very high surface tension, high > > enough that it was essentially fixed, then perhaps that could work? But > > then there could be problems with ill-conditioning with a very high > > surface tension. > > > > > > > > How complex is your domain? > > > > Not very. It consists of a liquid suspended (due to surface tension) > > between two metal posts. The liquid is surrounded by a gas flow. > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/schematic-3d-liquid-bridge-2.png > > > > I have gridded it using a block structured grid of 9 blocks, five in the > > liquid region and four in the gas. The terminology for the whole problem > > is a "liquid bridge". > > > > Cheers, > > Frank > > > > > > > > Paul > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > On Tue, 2010-04-06 at 12:58 +0200, nek5000-users at lists.mcs.anl.gov > > > wrote: > > > > NEK-NEK stands for the coupling of two independent NEK instances. Unfortunately this is still an experimental feature but if you're interested in we can set up something for you. > > > > > > Hello Stefan, > > > > > > If I can make up a grid, is getting an instance of the NEK-NEK > > > capability working something you are willing to work with me to get > > > running? Couple of questions: How experimental is the NEK-NEK > > > capability? And is there a specific application or class of problems > > > driving it? > > > > > > Cheers, > > > Frank > > > > > > > > > > > Stefan > > > > > > > > > > > > On Apr 6, 2010, at 12:54 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > > > Hello Stefan, > > > > > > > > > > Thanks, that fixed it. By the way, (from your earlier email) what does > > > > > NEK-NEK stand for? > > > > > > > > > > Cheers, > > > > > Frank > > > > > > > > > > On Tue, 2010-04-06 at 12:45 +0200, nek5000-users at lists.mcs.anl.gov > > > > > wrote: > > > > >> Hi Frank, > > > > >> > > > > >> On Apr 6, 2010, at 12:32 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > > >>> Am I correct in understanding that all components of velocity are > > > > >>> stored at the same locations (the Gauss?Lobatto?Legendre points), while > > > > >>> the pressure is located at the Gauss?Legendre points? This being in > > > > >>> contrast to a MAC type staggered grid, where each velocity component > > > > >>> resides at different spatial locations. > > > > >>> > > > > >> Yes that's correct! In NEK two different methods are implemented: > > > > >> > > > > >> PN/PN: (v,p) are defined on the GLL points > > > > >> PN/PN-2: v is defined on the GLL points and p on the GL points > > > > >> > > > > >> > > > > >>> VisIt could not read from the file > > > > >>> "/home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001". > > > > >>> > > > > >>> The generated error message was: > > > > >>> > > > > >>> There was an error > > > > >>> opening /home/fmuldoo/nek5_svn/examples/turbChannel-1/turbChannel0.f0001. It may be an invalid file. VisIt tried using the following file format readers to open the file: Silo > > > > >>> > > > > >>> When using the following metadata file: > > > > >>> > > > > >>> NEK5000 > > > > >>> version: 1.0 > > > > >>> filetemplate: turbChannel0.f%04d > > > > >>> firsttimestep: 1 > > > > >>> numtimesteps: 1 > > > > >> It seems like you're using a wrong filetemplate. Please try again with: > > > > >> filetemplate: turbChannel%01d.f%04d > > > > >> > > > > >> > > > > >> #Stefan > > > > >> > > > > >> _______________________________________________ > > > > >> Nek5000-users mailing list > > > > >> Nek5000-users at lists.mcs.anl.gov > > > > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > > -- > > > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > > > Technische Universit?t Wien (Technical University of Vienna) > > > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > > > > Mechanics and Heat Transfer) > > > > > Resselgasse 3 > > > > > 1040 Wien > > > > > Tel: +4315880132232 > > > > > Fax: +4315880132299 > > > > > Cell:+436765203470 > > > > > fmuldoo (skype) > > > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > > > > > _______________________________________________ > > > > > Nek5000-users mailing list > > > > > Nek5000-users at lists.mcs.anl.gov > > > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > > > > > _______________________________________________ > > > > Nek5000-users mailing list > > > > Nek5000-users at lists.mcs.anl.gov > > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -- > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > Technische Universit?t Wien (Technical University of Vienna) > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > > Mechanics and Heat Transfer) > > > Resselgasse 3 > > > 1040 Wien > > > Tel: +4315880132232 > > > Fax: +4315880132299 > > > Cell:+436765203470 > > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > _______________________________________________ > > > Nek5000-users mailing list > > > Nek5000-users at lists.mcs.anl.gov > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 7 09:54:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 09:54:53 -0500 (CDT) Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270651412.8715.54.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> <1270651412.8715.54.camel@localhost.localdomain> Message-ID: Hi Frank, Actually, the only thing that would be specified at the interface is the surface tension sigma, which would generate a jump in the stress across the interface. The fluid and surface would dynamically accommodate to these stresses - and would come to a steady state geometry if that's the what the dynamics dictates. The temperature would still satisfy the heat equation, and of course you could have different rho-Cp and k in each region. The code will generate the correct jump in pressure according to the surface tension. (We can check this with the case of a spherical drop.) Of course, w/o Lee around we'll have to sort all this out to make certain it does what we expect... but I'm fairly confident that it will. Paul > Paul, > > Great to hear that. Question; an internal interface has the meaning of > an internal boundary condition at which velocity and temperature, but > not pressure, boundary conditions can be set? > > Since the normal velocity at the interface is set to zero and the > interface completely separates the two fluids, the absolute value of the > pressure in the two fluids is independent in the model I have in mind. > To put in other words, no pressure gradients across the interface exist > in the model. But I guess that will always be the case in the spectral > element method, as long as the interface is not inside an element. > > Cheers, > Frank From nek5000-users at lists.mcs.anl.gov Wed Apr 7 10:09:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 07 Apr 2010 17:09:44 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> <1270651412.8715.54.camel@localhost.localdomain> Message-ID: <1270652984.8715.73.camel@localhost.localdomain> On Wed, 2010-04-07 at 09:54 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Actually, the only thing that would be specified at the interface > is the surface tension sigma, which would generate a jump in the > stress across the interface. The fluid and surface would dynamically > accommodate to these stresses - and would come to a steady state > geometry if that's the what the dynamics dictates. The temperature > would still satisfy the heat equation, and of course you could have > different rho-Cp and k in each region. > > The code will generate the correct jump in pressure according to the > surface tension. (We can check this with the case of a spherical > drop.) > > Of course, w/o Lee around we'll have to sort all this out to make > certain it does what we expect... but I'm fairly confident that it > will. > > Paul Hi Paul, OK, I think I understand it. Taking the surface tension coefficient as: sigma = sigma0 - sigma1*T The size of the jump in the pressure between the liquid and the gas would be determined by the size of sigma0 and the surface curvature. This would mean then that, assuming an incompressible fluid, the only effect of sigma0 would be to define the mean pressure difference between the gas and the liquid. Do this view seem correct? Cheers, Frank > > > Paul, > > > > Great to hear that. Question; an internal interface has the meaning of > > an internal boundary condition at which velocity and temperature, but > > not pressure, boundary conditions can be set? > > > > Since the normal velocity at the interface is set to zero and the > > interface completely separates the two fluids, the absolute value of the > > pressure in the two fluids is independent in the model I have in mind. > > To put in other words, no pressure gradients across the interface exist > > in the model. But I guess that will always be the case in the spectral > > element method, as long as the interface is not inside an element. > > > > Cheers, > > Frank > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 7 10:16:10 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 10:16:10 -0500 (CDT) Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270652984.8715.73.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> <1270651412.8715.54.camel@localhost.localdomain> <1270652984.8715.73.camel@localhost.localdomain> Message-ID: Yes - I think that's it. I'm trying to sort out an issue with the ALE right now... Paul On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > On Wed, 2010-04-07 at 09:54 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Actually, the only thing that would be specified at the interface > is the surface tension sigma, which would generate a jump in the > stress across the interface. The fluid and surface would dynamically > accommodate to these stresses - and would come to a steady state > geometry if that's the what the dynamics dictates. The temperature > would still satisfy the heat equation, and of course you could have > different rho-Cp and k in each region. > > The code will generate the correct jump in pressure according to the > surface tension. (We can check this with the case of a spherical > drop.) > > Of course, w/o Lee around we'll have to sort all this out to make > certain it does what we expect... but I'm fairly confident that it > will. > > Paul Hi Paul, OK, I think I understand it. Taking the surface tension coefficient as: sigma = sigma0 - sigma1*T The size of the jump in the pressure between the liquid and the gas would be determined by the size of sigma0 and the surface curvature. This would mean then that, assuming an incompressible fluid, the only effect of sigma0 would be to define the mean pressure difference between the gas and the liquid. Do this view seem correct? Cheers, Frank > > > Paul, > > > > Great to hear that. Question; an internal interface has the meaning of > > an internal boundary condition at which velocity and temperature, but > > not pressure, boundary conditions can be set? > > > > Since the normal velocity at the interface is set to zero and the > > interface completely separates the two fluids, the absolute value of the > > pressure in the two fluids is independent in the model I have in mind. > > To put in other words, no pressure gradients across the interface exist > > in the model. But I guess that will always be the case in the spectral > > element method, as long as the interface is not inside an element. > > > > Cheers, > > Frank > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 7 11:42:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 07 Apr 2010 22:12:03 +0530 Subject: [Nek5000-users] Extracting data from fld files Message-ID: <4BBCB5DB.30504@iitk.ac.in> Dear Nek devs, I would like to extract the time series of fields at a particular point in the geometry from the fld files and dump it into an ASCII file. For ex: In a box of size [0,1]x[0,1], how do I extract the fields at say (0.5, 0.5). Is it possible to directly access the field data corresponding to a specific geometric location (even though it's on another processor). Mani chandra From nek5000-users at lists.mcs.anl.gov Wed Apr 7 11:58:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 18:58:21 +0200 Subject: [Nek5000-users] Extracting data from fld files In-Reply-To: <4BBCB5DB.30504@iitk.ac.in> References: <4BBCB5DB.30504@iitk.ac.in> Message-ID: <0E5B469C-0058-4BE2-BE66-EBBFC402FA34@lav.mavt.ethz.ch> There are multiple options: (a) use intpts() - interpolation (can be done online or as a postprocessing step) see here: http://nek5000.mcs.anl.gov/index.php/Data_processing_example (b) use VisIt - extract a point Stefan On Apr 7, 2010, at 6:42 PM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nek devs, > > I would like to extract the time series of fields at a particular point in the geometry from the fld files and dump it into an ASCII file. For ex: In a box of size [0,1]x[0,1], how do I extract the fields at say (0.5, 0.5). Is it possible to directly access the field data corresponding to a specific geometric location (even though it's on another processor). > > Mani chandra > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 7 14:29:57 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 08 Apr 2010 00:59:57 +0530 Subject: [Nek5000-users] Handling large data Message-ID: <4BBCDD35.9020901@iitk.ac.in> Dear Nek devs, This is not a Nek5k specific question, but given your experience performing some massive simulations (https://nek5000.mcs.anl.gov/index.php/Visualization_Gallery) which must have generated a huge amount of data, could you maybe give some tips on how best to handle and organize data? Right now, I do the most naive thing possible: putting separate cases in different folders with the folder name indicating the parameters (case_X_para1_para2..) and constantly keep transferring the data (not a script!) to avoid filling up our quota in the cluster's hard disk. I'd just like to know how things are done on the really big machines. Thanks! Mani chandra From nek5000-users at lists.mcs.anl.gov Wed Apr 7 16:25:40 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 7 Apr 2010 23:25:40 +0200 Subject: [Nek5000-users] Handling large data In-Reply-To: <4BBCDD35.9020901@iitk.ac.in> References: <4BBCDD35.9020901@iitk.ac.in> Message-ID: <82BBED34-AD3E-49E5-9EED-7A9F806F486D@lav.mavt.ethz.ch> Dear Mani, I performed a single simulation producing 100TB of raw data. This is so far the most data intensive simulation we did with NEK. I am not sure what you have exactly in mind but I am happy to share some of my experience. For large scale computations you're most concerned about I/O performance, data analysis and data transfer. I/O Performance ---------------------- The write throughput depends on many parameters: - data layout You'll get the best write performance by dumping large contiguous blocks. - dump data in parallel Here you have multiple options. It turns out that a two phase approach where only a subset of mpi-tasks actually perform the I/O works best. If all mpi tasks are writing into a shared or separate file you'll run into filesystem and network contentions effects. In addition the overhead of handling thousands of files slows down the metadata server which will become your bottleneck at some point. The optimal number of I/O nodes depends on the parallel filesystem configuration. On Intrepid (ANL's BG/P) you have to use around 512 I/O nodes to get close to the peak write throughput. In most simulations the amount of data to dump per mpi-tasks is only a few MB. However to get peak throughput you'll need several hundred MB per mpi-task. The peak write throughput rate is ~80 GB/s on Intrepid however in a typical large scale simulation you'll get only a few GB/s. If I recall correct I got around 6 GB/s using 32 racks (a rack has 4096 cores) on Intrepid. Data Analysis ------------------- Similar story here. Reading the data is often the most time consuming part even if you some expensive volume rendering of big datasets.The performance problems are very similar here however the data access pattern can be even more irregular and read-ahead caching algorithms will not work well in this case. In the past we have used VisIt on a few hundred processors to do the data analysis. The read throughput rates are rather low (around 1 GB/s) but this depends on your access pattern. Slicing and contouring operations can be speeded up by some additional metadata. Together with some VisIt developers we were able to improve the NEK5000 reader performance in VisIt significantly. A slice operation does not take more than a few seconds for a 50GB file even on a few processors. Data Transfer ------------------ This can become really a pain. You definitely need a high-speed connection between your home institution and the supercomputer where you computed the data. Using GridFTP we have been able to transfer the data with an averaged throughput of ~40 MB/s. So you still need 1 month to transfer 100TB ;) Stefan On Apr 7, 2010, at 9:29 PM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nek devs, > > This is not a Nek5k specific question, but given your experience performing some massive simulations (https://nek5000.mcs.anl.gov/index.php/Visualization_Gallery) which must have generated a huge amount of data, could you maybe give some tips on how best to handle and organize data? Right now, I do the most naive thing possible: putting separate cases in different folders with the folder name indicating the parameters (case_X_para1_para2..) and constantly keep transferring the data (not a script!) to avoid filling up our quota in the cluster's hard disk. > > I'd just like to know how things are done on the really big machines. Thanks! > > Mani chandra > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 8 04:03:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 8 Apr 2010 04:03:55 -0500 (CDT) Subject: [Nek5000-users] Question about method & error In-Reply-To: References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> <1270651412.8715.54.camel@localhost.localdomain> <1270652984.8715.73.camel@localhost.localdomain> Message-ID: Frank, I think that the internal fluid interface feature is now working in the latest svn repo. You will need to identify the bdry between the two fluids with "msi" on each given face. Then you would specify surface tension sigma = blah blah blah in userbc, where blah is your desired function. Note that you must also set lx1m, etc. to lx1 in SIZE, and IFMVBD, IFSTRS to T in the .rea file. I'll try to help you set this up - but am saturated for the next 7 days because of mtgs. I've tried a couple of 2D examples and they work sufficiently well for your purposes (I think - but haven't investigated too closely). I'll try to post some examples in the next 48 hours. Paul On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > Yes - I think that's it. > > I'm trying to sort out an issue with the ALE right now... > > Paul > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> On Wed, 2010-04-07 at 09:54 -0500, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Frank, >> >> Actually, the only thing that would be specified at the interface >> is the surface tension sigma, which would generate a jump in the stress >> across the interface. The fluid and surface would dynamically >> accommodate to these stresses - and would come to a steady state >> geometry if that's the what the dynamics dictates. The temperature >> would still satisfy the heat equation, and of course you could have >> different rho-Cp and k in each region. >> >> The code will generate the correct jump in pressure according to the >> surface tension. (We can check this with the case of a spherical >> drop.) >> >> Of course, w/o Lee around we'll have to sort all this out to make >> certain it does what we expect... but I'm fairly confident that it >> will. >> >> Paul > > Hi Paul, > > OK, I think I understand it. Taking the surface tension coefficient as: > sigma = sigma0 - sigma1*T > The size of the jump in the pressure between the liquid and the gas > would be determined by the size of sigma0 and the surface curvature. > This would mean then that, assuming an incompressible fluid, the only > effect of sigma0 would be to define the mean pressure difference between > the gas and the liquid. Do this view seem correct? > > Cheers, > Frank > > >> >> > Paul, >> > > Great to hear that. Question; an internal interface has the meaning of >> > an internal boundary condition at which velocity and temperature, but >> > not pressure, boundary conditions can be set? > > Since the normal >> velocity at the interface is set to zero and the >> > interface completely separates the two fluids, the absolute value of the >> > pressure in the two fluids is independent in the model I have in mind. >> > To put in other words, no pressure gradients across the interface exist >> > in the model. But I guess that will always be the case in the spectral >> > element method, as long as the interface is not inside an element. >> > > Cheers, >> > Frank >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit??t Wien (Technical University of Vienna) > Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 8 04:31:01 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 08 Apr 2010 11:31:01 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> <1270651412.8715.54.camel@localhost.localdomain> <1270652984.8715.73.camel@localhost.localdomain> Message-ID: <1270719061.8715.101.camel@localhost.localdomain> Hi Paul, Thanks very much, that is great to hear. Is it correct that the latest version is at:? https://svn.mcs.anl.gov/repos/nek5/ I will try to set this up now, first thing being getting the grid (built in Gambit) into the solver. Cheers, Frank On Thu, 2010-04-08 at 04:03 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > I think that the internal fluid interface feature is now working > in the latest svn repo. > > You will need to identify the bdry between the two fluids with "msi" > on each given face. Then you would specify surface tension > > sigma = blah blah blah > > in userbc, where blah is your desired function. > > Note that you must also set lx1m, etc. to lx1 in SIZE, and > IFMVBD, IFSTRS to T in the .rea file. > > I'll try to help you set this up - but am saturated for the next > 7 days because of mtgs. > > I've tried a couple of 2D examples and they work sufficiently > well for your purposes (I think - but haven't investigated > too closely). I'll try to post some examples in the next 48 hours. > > Paul > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Yes - I think that's it. > > > > I'm trying to sort out an issue with the ALE right now... > > > > Paul > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > >> On Wed, 2010-04-07 at 09:54 -0500, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Frank, > >> > >> Actually, the only thing that would be specified at the interface > >> is the surface tension sigma, which would generate a jump in the stress > >> across the interface. The fluid and surface would dynamically > >> accommodate to these stresses - and would come to a steady state > >> geometry if that's the what the dynamics dictates. The temperature > >> would still satisfy the heat equation, and of course you could have > >> different rho-Cp and k in each region. > >> > >> The code will generate the correct jump in pressure according to the > >> surface tension. (We can check this with the case of a spherical > >> drop.) > >> > >> Of course, w/o Lee around we'll have to sort all this out to make > >> certain it does what we expect... but I'm fairly confident that it > >> will. > >> > >> Paul > > > > Hi Paul, > > > > OK, I think I understand it. Taking the surface tension coefficient as: > > sigma = sigma0 - sigma1*T > > The size of the jump in the pressure between the liquid and the gas > > would be determined by the size of sigma0 and the surface curvature. > > This would mean then that, assuming an incompressible fluid, the only > > effect of sigma0 would be to define the mean pressure difference between > > the gas and the liquid. Do this view seem correct? > > > > Cheers, > > Frank > > > > > >> > >> > Paul, > >> > > Great to hear that. Question; an internal interface has the meaning of > >> > an internal boundary condition at which velocity and temperature, but > >> > not pressure, boundary conditions can be set? > > Since the normal > >> velocity at the interface is set to zero and the > >> > interface completely separates the two fluids, the absolute value of the > >> > pressure in the two fluids is independent in the model I have in mind. > >> > To put in other words, no pressure gradients across the interface exist > >> > in the model. But I guess that will always be the case in the spectral > >> > element method, as long as the interface is not inside an element. > >> > > Cheers, > >> > Frank > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Apr 8 06:54:31 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 8 Apr 2010 06:54:31 -0500 (CDT) Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270719061.8715.101.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> <1270651412.8715.54.camel@localhost.localdomain> <1270652984.8715.73.camel@localhost.localdomain> <1270719061.8715.101.camel@localhost.localdomain> Message-ID: Yes - this is correct. If you can give me a rough idea of dimensions (e.g., minor-major diameters of the bridge), I could knock something out in prenek for you. Paul On Thu, 8 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, Thanks very much, that is great to hear. Is it correct that the latest version is at:? https://svn.mcs.anl.gov/repos/nek5/ I will try to set this up now, first thing being getting the grid (built in Gambit) into the solver. Cheers, Frank On Thu, 2010-04-08 at 04:03 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > I think that the internal fluid interface feature is now working > in the latest svn repo. > > You will need to identify the bdry between the two fluids with "msi" > on each given face. Then you would specify surface tension > > sigma = blah blah blah > > in userbc, where blah is your desired function. > > Note that you must also set lx1m, etc. to lx1 in SIZE, and > IFMVBD, IFSTRS to T in the .rea file. > > I'll try to help you set this up - but am saturated for the next > 7 days because of mtgs. > > I've tried a couple of 2D examples and they work sufficiently > well for your purposes (I think - but haven't investigated > too closely). I'll try to post some examples in the next 48 hours. > > Paul > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Yes - I think that's it. > > > > I'm trying to sort out an issue with the ALE right now... > > > > Paul > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > >> On Wed, 2010-04-07 at 09:54 -0500, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Frank, > >> > >> Actually, the only thing that would be specified at the interface > >> is the surface tension sigma, which would generate a jump in the stress > >> across the interface. The fluid and surface would dynamically > >> accommodate to these stresses - and would come to a steady state > >> geometry if that's the what the dynamics dictates. The temperature > >> would still satisfy the heat equation, and of course you could have > >> different rho-Cp and k in each region. > >> > >> The code will generate the correct jump in pressure according to the > >> surface tension. (We can check this with the case of a spherical > >> drop.) > >> > >> Of course, w/o Lee around we'll have to sort all this out to make > >> certain it does what we expect... but I'm fairly confident that it > >> will. > >> > >> Paul > > > > Hi Paul, > > > > OK, I think I understand it. Taking the surface tension coefficient as: > > sigma = sigma0 - sigma1*T > > The size of the jump in the pressure between the liquid and the gas > > would be determined by the size of sigma0 and the surface curvature. > > This would mean then that, assuming an incompressible fluid, the only > > effect of sigma0 would be to define the mean pressure difference between > > the gas and the liquid. Do this view seem correct? > > > > Cheers, > > Frank > > > > > >> > >> > Paul, > >> > > Great to hear that. Question; an internal interface has the meaning of > >> > an internal boundary condition at which velocity and temperature, but > >> > not pressure, boundary conditions can be set? > > Since the normal > >> velocity at the interface is set to zero and the > >> > interface completely separates the two fluids, the absolute value of the > >> > pressure in the two fluids is independent in the model I have in mind. > >> > To put in other words, no pressure gradients across the interface exist > >> > in the model. But I guess that will always be the case in the spectral > >> > element method, as long as the interface is not inside an element. > >> > > Cheers, > >> > Frank > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 8 12:17:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 08 Apr 2010 19:17:59 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> <1270651412.8715.54.camel@localhost.localdomain> <1270652984.8715.73.camel@localhost.localdomain> <1270719061.8715.101.camel@localhost.localdomain> Message-ID: <1270747080.8715.107.camel@localhost.localdomain> On Thu, 2010-04-08 at 06:54 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Yes - this is correct. > > If you can give me a rough idea of dimensions (e.g., minor-major > diameters of the bridge), I could knock something out in prenek > for you. Hi Paul, I had to step out for a bit, back for the rest of the night though. That would be very kind of you. The dimensions are: http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/schematic-3d-liquid-bridge-3.png Cheers, Frank > > Paul > > > On Thu, 8 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > Thanks very much, that is great to hear. Is it correct that the latest > version is at:? > https://svn.mcs.anl.gov/repos/nek5/ > > I will try to set this up now, first thing being getting the grid (built > in Gambit) into the solver. > > Cheers, > Frank > > > On Thu, 2010-04-08 at 04:03 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Frank, > > > > I think that the internal fluid interface feature is now working > > in the latest svn repo. > > > > You will need to identify the bdry between the two fluids with "msi" > > on each given face. Then you would specify surface tension > > > > sigma = blah blah blah > > > > in userbc, where blah is your desired function. > > > > Note that you must also set lx1m, etc. to lx1 in SIZE, and > > IFMVBD, IFSTRS to T in the .rea file. > > > > I'll try to help you set this up - but am saturated for the next > > 7 days because of mtgs. > > > > I've tried a couple of 2D examples and they work sufficiently > > well for your purposes (I think - but haven't investigated > > too closely). I'll try to post some examples in the next 48 hours. > > > > Paul > > > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > > Yes - I think that's it. > > > > > > I'm trying to sort out an issue with the ALE right now... > > > > > > Paul > > > > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > >> On Wed, 2010-04-07 at 09:54 -0500, nek5000-users at lists.mcs.anl.gov > > > wrote: > > >> Hi Frank, > > >> > > >> Actually, the only thing that would be specified at the interface > > >> is the surface tension sigma, which would generate a jump in the stress > > >> across the interface. The fluid and surface would dynamically > > >> accommodate to these stresses - and would come to a steady state > > >> geometry if that's the what the dynamics dictates. The temperature > > >> would still satisfy the heat equation, and of course you could have > > >> different rho-Cp and k in each region. > > >> > > >> The code will generate the correct jump in pressure according to the > > >> surface tension. (We can check this with the case of a spherical > > >> drop.) > > >> > > >> Of course, w/o Lee around we'll have to sort all this out to make > > >> certain it does what we expect... but I'm fairly confident that it > > >> will. > > >> > > >> Paul > > > > > > Hi Paul, > > > > > > OK, I think I understand it. Taking the surface tension coefficient as: > > > sigma = sigma0 - sigma1*T > > > The size of the jump in the pressure between the liquid and the gas > > > would be determined by the size of sigma0 and the surface curvature. > > > This would mean then that, assuming an incompressible fluid, the only > > > effect of sigma0 would be to define the mean pressure difference between > > > the gas and the liquid. Do this view seem correct? > > > > > > Cheers, > > > Frank > > > > > > > > >> > > >> > Paul, > > >> > > Great to hear that. Question; an internal interface has the meaning of > > >> > an internal boundary condition at which velocity and temperature, but > > >> > not pressure, boundary conditions can be set? > > Since the normal > > >> velocity at the interface is set to zero and the > > >> > interface completely separates the two fluids, the absolute value of the > > >> > pressure in the two fluids is independent in the model I have in mind. > > >> > To put in other words, no pressure gradients across the interface exist > > >> > in the model. But I guess that will always be the case in the spectral > > >> > element method, as long as the interface is not inside an element. > > >> > > Cheers, > > >> > Frank > > >> _______________________________________________ > > >> Nek5000-users mailing list > > >> Nek5000-users at lists.mcs.anl.gov > > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -- > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > Technische Universit?t Wien (Technical University of Vienna) > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > > Mechanics and Heat Transfer) > > > Resselgasse 3 > > > 1040 Wien > > > Tel: +4315880132232 > > > Fax: +4315880132299 Cell:+436765203470 > > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > _______________________________________________ > > > Nek5000-users mailing list > > > Nek5000-users at lists.mcs.anl.gov > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Apr 8 13:04:36 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 08 Apr 2010 23:34:36 +0530 Subject: [Nek5000-users] [*] Re: Handling large data In-Reply-To: <82BBED34-AD3E-49E5-9EED-7A9F806F486D@lav.mavt.ethz.ch> References: <4BBCDD35.9020901@iitk.ac.in> <82BBED34-AD3E-49E5-9EED-7A9F806F486D@lav.mavt.ethz.ch> Message-ID: <4BBE1AB4.2080009@iitk.ac.in> Hi, Thanks for the info. Those are really mind boggling numbers! Mani chandra On 04/08/2010 02:55 AM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Mani, > > I performed a single simulation producing 100TB of raw data. This is so far the most data intensive simulation we did with NEK. I am not sure what you have exactly in mind but I am happy to share some of my experience. For large scale computations you're most concerned about I/O performance, data analysis and data transfer. > > > I/O Performance > ---------------------- > The write throughput depends on many parameters: > > - data layout > You'll get the best write performance by dumping large contiguous blocks. > > - dump data in parallel > Here you have multiple options. It turns out that a two phase approach where only a subset of mpi-tasks actually perform the I/O works best. If all mpi tasks are writing into a shared or separate file you'll run into filesystem and network contentions effects. In addition the overhead of handling thousands of files slows down the metadata server which will become your bottleneck at some point. > The optimal number of I/O nodes depends on the parallel filesystem configuration. On Intrepid (ANL's BG/P) you have to use around 512 I/O nodes to get close to the peak write throughput. > > In most simulations the amount of data to dump per mpi-tasks is only a few MB. However to get peak throughput you'll need several hundred MB per mpi-task. The peak write throughput rate is ~80 GB/s on Intrepid however in a typical large scale simulation you'll get only a few GB/s. If I recall correct I got around 6 GB/s using 32 racks (a rack has 4096 cores) on Intrepid. > > > Data Analysis > ------------------- > Similar story here. Reading the data is often the most time consuming part even if you some expensive volume rendering of big datasets.The performance problems are very similar here however the data access pattern can be even more irregular and read-ahead caching algorithms will not work well in this case. In the past we have used VisIt on a few hundred processors to do the data analysis. The read throughput rates are rather low (around 1 GB/s) but this depends on your access pattern. Slicing and contouring operations can be speeded up by some additional metadata. Together with some VisIt developers we were able to improve the NEK5000 reader performance in VisIt significantly. A slice operation does not take more than a few seconds for a 50GB file even on a few processors. > > Data Transfer > ------------------ > This can become really a pain. You definitely need a high-speed connection between your home institution and the supercomputer where you computed the data. Using GridFTP we have been able to transfer the data with an averaged throughput of ~40 MB/s. So you still need 1 month to transfer 100TB ;) > > > > Stefan > > > > On Apr 7, 2010, at 9:29 PM, nek5000-users at lists.mcs.anl.gov wrote: > > >> Dear Nek devs, >> >> This is not a Nek5k specific question, but given your experience performing some massive simulations (https://nek5000.mcs.anl.gov/index.php/Visualization_Gallery) which must have generated a huge amount of data, could you maybe give some tips on how best to handle and organize data? Right now, I do the most naive thing possible: putting separate cases in different folders with the folder name indicating the parameters (case_X_para1_para2..) and constantly keep transferring the data (not a script!) to avoid filling up our quota in the cluster's hard disk. >> >> I'd just like to know how things are done on the really big machines. Thanks! >> >> Mani chandra >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > From nek5000-users at lists.mcs.anl.gov Thu Apr 8 15:40:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 8 Apr 2010 15:40:29 -0500 (CDT) Subject: [Nek5000-users] Question about method & error In-Reply-To: <1270747080.8715.107.camel@localhost.localdomain> References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> <1270651412.8715.54.camel@localhost.localdomain> <1270652984.8715.73.camel@localhost.localdomain> <1270719061.8715.101.camel@localhost.localdomain> <1270747080.8715.107.camel@localhost.localdomain> Message-ID: Hi Frank, Any idea of BCs for the gas phase? What about the Reynolds number? Cheers, Paul On Thu, 8 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > On Thu, 2010-04-08 at 06:54 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Yes - this is correct. > > If you can give me a rough idea of dimensions (e.g., minor-major > diameters of the bridge), I could knock something out in prenek > for you. Hi Paul, I had to step out for a bit, back for the rest of the night though. That would be very kind of you. The dimensions are: http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/schematic-3d-liquid-bridge-3.png Cheers, Frank > > Paul > > > On Thu, 8 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul, > > Thanks very much, that is great to hear. Is it correct that the latest > version is at:? > https://svn.mcs.anl.gov/repos/nek5/ > > I will try to set this up now, first thing being getting the grid (built > in Gambit) into the solver. > > Cheers, > Frank > > > On Thu, 2010-04-08 at 04:03 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Frank, > > > > I think that the internal fluid interface feature is now working > > in the latest svn repo. > > > > You will need to identify the bdry between the two fluids with "msi" > > on each given face. Then you would specify surface tension > > > > sigma = blah blah blah > > > > in userbc, where blah is your desired function. > > > > Note that you must also set lx1m, etc. to lx1 in SIZE, and > > IFMVBD, IFSTRS to T in the .rea file. > > > > I'll try to help you set this up - but am saturated for the next > > 7 days because of mtgs. > > > > I've tried a couple of 2D examples and they work sufficiently > > well for your purposes (I think - but haven't investigated > > too closely). I'll try to post some examples in the next 48 hours. > > > > Paul > > > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > > Yes - I think that's it. > > > > > > I'm trying to sort out an issue with the ALE right now... > > > > > > Paul > > > > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > >> On Wed, 2010-04-07 at 09:54 -0500, nek5000-users at lists.mcs.anl.gov > > > wrote: > > >> Hi Frank, > > >> > > >> Actually, the only thing that would be specified at the interface > > >> is the surface tension sigma, which would generate a jump in the stress > > >> across the interface. The fluid and surface would dynamically > > >> accommodate to these stresses - and would come to a steady state > > >> geometry if that's the what the dynamics dictates. The temperature > > >> would still satisfy the heat equation, and of course you could have > > >> different rho-Cp and k in each region. > > >> > > >> The code will generate the correct jump in pressure according to the > > >> surface tension. (We can check this with the case of a spherical > > >> drop.) > > >> > > >> Of course, w/o Lee around we'll have to sort all this out to make > > >> certain it does what we expect... but I'm fairly confident that it > > >> will. > > >> > > >> Paul > > > > > > Hi Paul, > > > > > > OK, I think I understand it. Taking the surface tension coefficient as: > > > sigma = sigma0 - sigma1*T > > > The size of the jump in the pressure between the liquid and the gas > > > would be determined by the size of sigma0 and the surface curvature. > > > This would mean then that, assuming an incompressible fluid, the only > > > effect of sigma0 would be to define the mean pressure difference between > > > the gas and the liquid. Do this view seem correct? > > > > > > Cheers, > > > Frank > > > > > > > > >> > > >> > Paul, > > >> > > Great to hear that. Question; an internal interface has the meaning of > > >> > an internal boundary condition at which velocity and temperature, but > > >> > not pressure, boundary conditions can be set? > > Since the normal > > >> velocity at the interface is set to zero and the > > >> > interface completely separates the two fluids, the absolute value of the > > >> > pressure in the two fluids is independent in the model I have in mind. > > >> > To put in other words, no pressure gradients across the interface exist > > >> > in the model. But I guess that will always be the case in the spectral > > >> > element method, as long as the interface is not inside an element. > > >> > > Cheers, > > >> > Frank > > >> _______________________________________________ > > >> Nek5000-users mailing list > > >> Nek5000-users at lists.mcs.anl.gov > > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -- > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > Technische Universit?t Wien (Technical University of Vienna) > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > > Mechanics and Heat Transfer) > > > Resselgasse 3 > > > 1040 Wien > > > Tel: +4315880132232 > > > Fax: +4315880132299 Cell:+436765203470 > > > fmuldoo (skype) > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > _______________________________________________ > > > Nek5000-users mailing list > > > Nek5000-users at lists.mcs.anl.gov > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 8 16:12:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 08 Apr 2010 23:12:00 +0200 Subject: [Nek5000-users] Question about method & error In-Reply-To: References: <1270549972.20672.44.camel@localhost.localdomain> <2600CA48-C2B2-45BD-B2CC-43D004881C88@lav.mavt.ethz.ch> <1270551278.20672.58.camel@localhost.localdomain> <8AA93010-7F59-433E-89D6-AFC057D7A290@lav.mavt.ethz.ch> <1270638602.8715.21.camel@localhost.localdomain> <1270641161.8715.36.camel@localhost.localdomain> <1270650259.8715.44.camel@localhost.localdomain> <1270651412.8715.54.camel@localhost.localdomain> <1270652984.8715.73.camel@localhost.localdomain> <1270719061.8715.101.camel@localhost.localdomain> <1270747080.8715.107.camel@localhost.localdomain> Message-ID: <1270761120.8715.122.camel@localhost.localdomain> On Thu, 2010-04-08 at 15:40 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Any idea of BCs for the gas phase? Hi Paul, For gas phase, a parabolic profile (in the radial direction) would be fine. For the outlet, a convective BC should be OK. > > What about the Reynolds number? The thermocapillary Reynolds number is 2400. It is defined as: sigma1*deltaT/(density*Kinematic_Viscosity**2) where sigma1 describes the linear variation of the surface tension coefficient with temperature (i.e., sigma = sigma0 - sigma1*T) deltaT --> is the temperature difference between the top and bottom walls The density of the gas is 1/1000 of the liquid. The Kinematic_Viscosity of the gas is 1/10 of the liquid. Cheers, Frank > > Cheers, > > Paul > > > On Thu, 8 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > On Thu, 2010-04-08 at 06:54 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Yes - this is correct. > > > > If you can give me a rough idea of dimensions (e.g., minor-major > > diameters of the bridge), I could knock something out in prenek > > for you. > > Hi Paul, > > I had to step out for a bit, back for the rest of the night though. > That would be very kind of you. The dimensions are: > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/temp/schematic-3d-liquid-bridge-3.png > > Cheers, > Frank > > > > > Paul > > > > > > On Thu, 8 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Hi Paul, > > > > Thanks very much, that is great to hear. Is it correct that the latest > > version is at:? > > https://svn.mcs.anl.gov/repos/nek5/ > > > > I will try to set this up now, first thing being getting the grid (built > > in Gambit) into the solver. > > > > Cheers, > > Frank > > > > > > On Thu, 2010-04-08 at 04:03 -0500, nek5000-users at lists.mcs.anl.gov > > wrote: > > > Frank, > > > > > > I think that the internal fluid interface feature is now working > > > in the latest svn repo. > > > > > > You will need to identify the bdry between the two fluids with "msi" > > > on each given face. Then you would specify surface tension > > > > > > sigma = blah blah blah > > > > > > in userbc, where blah is your desired function. > > > > > > Note that you must also set lx1m, etc. to lx1 in SIZE, and > > > IFMVBD, IFSTRS to T in the .rea file. > > > > > > I'll try to help you set this up - but am saturated for the next > > > 7 days because of mtgs. > > > > > > I've tried a couple of 2D examples and they work sufficiently > > > well for your purposes (I think - but haven't investigated > > > too closely). I'll try to post some examples in the next 48 hours. > > > > > > Paul > > > > > > > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > > > > > Yes - I think that's it. > > > > > > > > I'm trying to sort out an issue with the ALE right now... > > > > > > > > Paul > > > > > > > > > > > > On Wed, 7 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > > > >> On Wed, 2010-04-07 at 09:54 -0500, nek5000-users at lists.mcs.anl.gov > > > > wrote: > > > >> Hi Frank, > > > >> > > > >> Actually, the only thing that would be specified at the interface > > > >> is the surface tension sigma, which would generate a jump in the stress > > > >> across the interface. The fluid and surface would dynamically > > > >> accommodate to these stresses - and would come to a steady state > > > >> geometry if that's the what the dynamics dictates. The temperature > > > >> would still satisfy the heat equation, and of course you could have > > > >> different rho-Cp and k in each region. > > > >> > > > >> The code will generate the correct jump in pressure according to the > > > >> surface tension. (We can check this with the case of a spherical > > > >> drop.) > > > >> > > > >> Of course, w/o Lee around we'll have to sort all this out to make > > > >> certain it does what we expect... but I'm fairly confident that it > > > >> will. > > > >> > > > >> Paul > > > > > > > > Hi Paul, > > > > > > > > OK, I think I understand it. Taking the surface tension coefficient as: > > > > sigma = sigma0 - sigma1*T > > > > The size of the jump in the pressure between the liquid and the gas > > > > would be determined by the size of sigma0 and the surface curvature. > > > > This would mean then that, assuming an incompressible fluid, the only > > > > effect of sigma0 would be to define the mean pressure difference between > > > > the gas and the liquid. Do this view seem correct? > > > > > > > > Cheers, > > > > Frank > > > > > > > > > > > >> > > > >> > Paul, > > > >> > > Great to hear that. Question; an internal interface has the meaning of > > > >> > an internal boundary condition at which velocity and temperature, but > > > >> > not pressure, boundary conditions can be set? > > Since the normal > > > >> velocity at the interface is set to zero and the > > > >> > interface completely separates the two fluids, the absolute value of the > > > >> > pressure in the two fluids is independent in the model I have in mind. > > > >> > To put in other words, no pressure gradients across the interface exist > > > >> > in the model. But I guess that will always be the case in the spectral > > > >> > element method, as long as the interface is not inside an element. > > > >> > > Cheers, > > > >> > Frank > > > >> _______________________________________________ > > > >> Nek5000-users mailing list > > > >> Nek5000-users at lists.mcs.anl.gov > > > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > -- > > > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > > > Technische Universit?t Wien (Technical University of Vienna) > > > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > > > Mechanics and Heat Transfer) > > > > Resselgasse 3 > > > > 1040 Wien > > > > Tel: +4315880132232 > > > > Fax: +4315880132299 Cell:+436765203470 > > > > fmuldoo (skype) > > > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > > > > > _______________________________________________ > > > > Nek5000-users mailing list > > > > Nek5000-users at lists.mcs.anl.gov > > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Apr 8 16:40:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 8 Apr 2010 16:40:06 -0500 (CDT) Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: <1229853370.4982311270762555451.JavaMail.root@neo-mail-3> Message-ID: <1950630819.4983791270762806762.JavaMail.root@neo-mail-3> Hi Paul, We tried a few simple geometries with the new midpoint feature and did have some success, however we are also experiencing a new learning curve with the feature and thought you could shine some light on it. We tried with only one element and have been successful.? We?then tried with many elements, including all midpoints in the curved side section, and we received the "vanishing jacobian" error. Next, we tried removing from the curved side section; internal edges. So, any midpoints on edges that were "interior" to the geometry.? My best way to explain this would be midpoints which lie on edges that ?do not see a boundary (meaning the edge is shared by elements on all sides.)? This ?left us with only midpoints on the outer surface of the geometry, which we were able to deform quite nicely. However, we did reach a threshold at which point we got the "vanishing jacobian" again. So this brings up two questions: 1.?? Is there no support for?internal edges, meaning only midpoints on the surface of the geometry can be deformed? (If so, I think that is not an issue but good information to have). 2.? Is there a threshold?distance?from the midpoint to the undeformed edge?for it to work?? Markus ran a?case where?the following worked: 10 ?1 ? 0.75000 ? ? -0.090000 ? ? ?0.750000 ? ? ? 0.00000 ? ? ? 0.00000??????? m ? 9 ?3 ? 0.75000 ? ? -0.090000 ? ? ?0.750000 ? ? ? 0.00000?????? 0.00000 ? ???? m But, below?did not.????? 10 ?1 ? 0.75000 ? ? -0.100000 ? ? ?0.750000 ? ? ? 0.00000 ? ? ? 0.00000?????? m ? 9 ?3 ? 0.75000 ? ? -0.100000 ? ? ?0.750000 ? ? ? 0.00000???????0.00000 ? ??? m Thanks for any insight you can provide with this and the new feature! Regards, Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, April 5, 2010 10:17:21 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Representing Curved Side in any plane Hey Paul, Sounds great! And I think this is exactly what we needed! We will try it tomorrow. Thanks again, Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, April 5, 2010 9:29:33 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Representing Curved Side in any plane Hi, I've just added the midside-node support to the current svn repo for nek. Sorry - I thought I had upgraded this in October but apparently had not committed to the repo then. Hopefully all should work -- I retested my original benchmark w/ this new version and it is functioning. Please let me know if this now works for you. You should be able to modify any one of the 12 edges. Paul _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Apr 9 03:25:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 03:25:55 -0500 (CDT) Subject: [Nek5000-users] question about comilers In-Reply-To: <4BBEA6F7.5060003@vt.edu> References: <4BBEA6F7.5060003@vt.edu> Message-ID: Hi Mark, g95 + gcc I think is fine... cc'g the users list I believe the builds should just go through w/ the current repo version of the code. Paul On Fri, 9 Apr 2010, Mark Paul wrote: > > Hi Paul, > > Can you recommend a free set of compilers we can use on mac os x > snow leopard and for linux to run nekton, postx, and prex? We have > used pgi in the past but it is getting too pricey and always seems > to need an expensive upgrade to be supported on current os distributions etc. > > This would just be for small jobs and post-processing. I was going > to try gcc and gfortran but wanted to get your thoughts on this > before hacking around too much. > > Thanks, > > Mark > > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 03:36:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 10:36:55 +0200 Subject: [Nek5000-users] question about comilers In-Reply-To: References: <4BBEA6F7.5060003@vt.edu> Message-ID: <24BD7C37-9867-4C46-8260-409226CE075A@lav.mavt.ethz.ch> check the 'How to compile' section on the wiki to get a list of supported compilers. http://nek5000.mcs.anl.gov/index.php/UG Stefan On Apr 9, 2010, at 10:25 AM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Mark, > > g95 + gcc I think is fine... cc'g the users list > > I believe the builds should just go through w/ the current > repo version of the code. > > Paul > > On Fri, 9 Apr 2010, Mark Paul wrote: > >> >> Hi Paul, >> >> Can you recommend a free set of compilers we can use on mac os x >> snow leopard and for linux to run nekton, postx, and prex? We have >> used pgi in the past but it is getting too pricey and always seems >> to need an expensive upgrade to be supported on current os distributions etc. >> >> This would just be for small jobs and post-processing. I was going >> to try gcc and gfortran but wanted to get your thoughts on this >> before hacking around too much. >> >> Thanks, >> >> Mark >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 9 03:49:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 10:49:21 +0200 Subject: [Nek5000-users] question about comilers In-Reply-To: <24BD7C37-9867-4C46-8260-409226CE075A@lav.mavt.ethz.ch> References: <4BBEA6F7.5060003@vt.edu> <24BD7C37-9867-4C46-8260-409226CE075A@lav.mavt.ethz.ch> Message-ID: <12D4DD92-6B87-4341-8169-A4E0D31C50BC@lav.mavt.ethz.ch> Also, I am not sure if g95/gcc will work out of the box. So far we only support gfortran/gcc. Stefan On Apr 9, 2010, at 10:36 AM, nek5000-users at lists.mcs.anl.gov wrote: > check the 'How to compile' section on the wiki to get a list of supported compilers. > http://nek5000.mcs.anl.gov/index.php/UG > > Stefan > > On Apr 9, 2010, at 10:25 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> >> Hi Mark, >> >> g95 + gcc I think is fine... cc'g the users list >> >> I believe the builds should just go through w/ the current >> repo version of the code. >> >> Paul >> >> On Fri, 9 Apr 2010, Mark Paul wrote: >> >>> >>> Hi Paul, >>> >>> Can you recommend a free set of compilers we can use on mac os x >>> snow leopard and for linux to run nekton, postx, and prex? We have >>> used pgi in the past but it is getting too pricey and always seems >>> to need an expensive upgrade to be supported on current os distributions etc. >>> >>> This would just be for small jobs and post-processing. I was going >>> to try gcc and gfortran but wanted to get your thoughts on this >>> before hacking around too much. >>> >>> Thanks, >>> >>> Mark >>> >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 9 05:32:35 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 05:32:35 -0500 (CDT) Subject: [Nek5000-users] G.E. Global Research: Multiphase flow In-Reply-To: References: <4BB63B88.1090106@anl.gov> <4BBB583C.5040401@anl.gov> <6A4F689755EAA946AE0836B07D607AD101912127@CINMLVEM14.e2k.ad.ge.com> Message-ID: Greg, It's really not designed for multiphase -- sorry. Documentation is up and coming - google nek5000 for project webpage. There is an svn repo (documented on webpage). Principal strength of the code is incompressible and low-Mach number single phase at very large processor counts (>100,000). Paul On Fri, 9 Apr 2010, Laskowski, Gregory M (GE, Research) wrote: > Dear Ramesh and Paul- > > I would be interested to learn more about nek5000. I worked with it briefly > while I was a postdoc at Sandia National Labs in Livermore several years > ago. I'm sure it's advanced since then. Can you please either point me to > documentation of code capabilities or send me a report directly? > > I'm interested in DNS/LES of single phase and multiphase flows (2-phase and > 3-phase) for some fundamental (canonical) type flows. Does nek5000 have > (scalable) VOF or Levelset capabilities? > > Regards, > > Greg > > Gregory M. Laskowski, PhD > Computational Heat Transfer Lab > GE Global Research Center > Niskayuna NY 12309 USA > > (o) +1 518 387-6126 > > -----Original Message----- > From: Gupta, Anurag (GE, Research) > Sent: Tuesday, April 06, 2010 1:53 PM > To: bramesh at anl.gov > Cc: Paul Fischer; Laskowski, Gregory M (GE, Research) > Subject: RE: G.E. Global Research: Multiphase flow > > Hi Ramesh, Paul > > I've asked Greg Laskowski, who's leading one of the relevant projects here, > to get in touch with Paul directly. As I mentioned before, he was keenly > interested both in the experiment and the LES validation work that Paul > showed me during my visit > > regards > Anurag > > > -----Original Message----- > From: Ramesh Balakrishnan [mailto:bramesh at anl.gov] > Sent: Tuesday, April 06, 2010 11:50 AM > To: Gupta, Anurag (GE, Research) > Cc: Paul Fischer > Subject: Re: G.E. Global Research: Multiphase flow > > Hello Anurag, > I understand from Paul (cc'ed) that the nek5000 spectral element code does > handle complex geometries and does have the necessary models to handle > multiphase flows. That is, it does have Eulerian-Lagrangian coupling (it > does two way coupling). However, the Langrangian (particle) model and two > way coupling have not been tested extensively. If your team could tolerate a > bit of a learning curve, it would be worth the effort to try this out. On > the other hand, the Navier-Stokes solver in nek5000 scales extremely well. > It has been run on all 40 racks of the Blue Gene/P and has been run on > almost all the 70 racks of the Blue Gene/P at Juelich. Do let us know how > you'd wish to proceed. > > Sincerely, > Ramesh > > Ramesh Balakrishnan wrote: >> Hello Paul, >> I understand, from Anurag Gupta (cc'ed), that G.E. Global Research is >> going to be working on projects that involve multiphase incompressible >> flows in complex geometries. Could you please let us know if your >> nek5000 code handles multiphase flow with Lagrangian particles? >> >> Thanks, >> Ramesh > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 06:49:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 09 Apr 2010 07:49:23 -0400 Subject: [Nek5000-users] PN/PN and usrdiv In-Reply-To: <4BB0B22C.9030903@vt.edu> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> Message-ID: <4BBF1443.4090501@vt.edu> Hi, since I switched the pressure scheme from P_N/P_N-2 to PN/PN, as recommended by an earlier email, I have divergence trouble (simulation crashes) at the outflow, were a stabilization technique as in examples "peris" and "jet" is in place (adding divergence via usrdiv). I spent a long time trying to fix this (several test runs with increased outflow normal element length, increased divergence magnitude, mesh deformation to nozzle shape, which avoids crashing but has an adverse effect on the upstream flow,...) but I am becoming suspicious that usrdiv is just not used in PN/PN. Is that true? If so, how to fix it? Thanks, Markus From nek5000-users at lists.mcs.anl.gov Fri Apr 9 08:05:14 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 15:05:14 +0200 Subject: [Nek5000-users] PN/PN and usrdiv In-Reply-To: <4BBF1443.4090501@vt.edu> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> Message-ID: <10CBF68F-D237-4238-8D5B-170445303491@lav.mavt.ethz.ch> I have not used this feature for a while but usrdiv is used in plan4(). --- snip plan4.f --- 40 ! add user defined divergence to qtl 41 call col3 (h1,usrdiv,bm1,ntot1) 42 call add2 (qtl,h1,ntot1) --- snip plan4.f Stefan On Apr 9, 2010, at 1:49 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > since I switched the pressure scheme from P_N/P_N-2 to PN/PN, as recommended by an earlier email, I have divergence trouble (simulation crashes) at the outflow, were a stabilization technique as in examples "peris" and "jet" is in place (adding divergence via usrdiv). > I spent a long time trying to fix this (several test runs with increased outflow normal element length, increased divergence magnitude, mesh deformation to nozzle shape, which avoids crashing but has an adverse effect on the upstream flow,...) but I am becoming suspicious that usrdiv is just not used in PN/PN. > Is that true? If so, how to fix it? > > Thanks, > Markus > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 9 08:46:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 08:46:12 -0500 (CDT) Subject: [Nek5000-users] PN/PN and usrdiv In-Reply-To: <4BBF1443.4090501@vt.edu> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> Message-ID: Hi Markus, In your first sets of tests, did you notice that your peak speed went up dramatically ? ... In most of my cases I notice that the outflow velocity is "red" (i.e., fast) because of this condition. I'll check this w/ PnPn. Paul On Fri, 9 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > since I switched the pressure scheme from P_N/P_N-2 to PN/PN, as recommended > by an earlier email, I have divergence trouble (simulation crashes) at the > outflow, were a stabilization technique as in examples "peris" and "jet" is > in place (adding divergence via usrdiv). > I spent a long time trying to fix this (several test runs with increased > outflow normal element length, increased divergence magnitude, mesh > deformation to nozzle shape, which avoids crashing but has an adverse effect > on the upstream flow,...) but I am becoming suspicious that usrdiv is just > not used in PN/PN. > Is that true? If so, how to fix it? > > Thanks, > Markus > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 09:21:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 09:21:23 -0500 (CDT) Subject: [Nek5000-users] PN/PN and usrdiv In-Reply-To: <10CBF68F-D237-4238-8D5B-170445303491@lav.mavt.ethz.ch> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <10CBF68F-D237-4238-8D5B-170445303491@lav.mavt.ethz.ch> Message-ID: Yes - I just checked and it's indeed not doing anything for Pn-Pn. I'll get to this by the end of the afternoon... should take minimal effort to repair I think. Sorry about this Markus. Paul On Fri, 9 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > I have not used this feature for a while but usrdiv is used in plan4(). > > --- snip plan4.f --- > 40 ! add user defined divergence to qtl > 41 call col3 (h1,usrdiv,bm1,ntot1) > 42 call add2 (qtl,h1,ntot1) > --- snip plan4.f > > > Stefan > > > On Apr 9, 2010, at 1:49 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> since I switched the pressure scheme from P_N/P_N-2 to PN/PN, as recommended by an earlier email, I have divergence trouble (simulation crashes) at the outflow, were a stabilization technique as in examples "peris" and "jet" is in place (adding divergence via usrdiv). >> I spent a long time trying to fix this (several test runs with increased outflow normal element length, increased divergence magnitude, mesh deformation to nozzle shape, which avoids crashing but has an adverse effect on the upstream flow,...) but I am becoming suspicious that usrdiv is just not used in PN/PN. >> Is that true? If so, how to fix it? >> >> Thanks, >> Markus >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 09:33:18 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 09:33:18 -0500 Subject: [Nek5000-users] Seg. fault in running a backward facing step case. In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> Message-ID: <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> Hello, I am trying to simulate flow in a 3D backward facing step (BFS) geometry. I have attached the *.box file and n2to3.in file that I use to create the 3D geometry. For reference logfile, *.rea and *.usr files are attached. The code is compiled with GNU compiler and OpenMPI. The code is compiled for 16 processors and compiler.out file is attached as well. When I run the code, I get a seg. fault. After running the "gdb" tool on the core.* file, I get the following output. I have attached the gdb output file too. =========================================================================== Core was generated by `./nek5000'. Program terminated with signal 11, Segmentation fault. [New process 7652] #0 0x0000000000488768 in chcopy_ () =========================================================================== 3D BFS geometry has a wall at the bottom and symmetry b.c. at the top. But if I change the top b.c. with wall the simulation works. For reference I have attached the job output file. Initially, I thought the problem was with memory limitations on my cluster for a bigger geometry. So I tried a smaller geometry, but I still kept getting seg. faults. Help with solving this problem will be greatly appreciated. And sorry for attaching so many files. Thanks, Harish. -------------- next part -------------- A non-text attachment was scrubbed... Name: bfs.box Type: application/octet-stream Size: 1017 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: n2to3.in Type: application/octet-stream Size: 458 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logfile Type: application/octet-stream Size: 7164 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bfs3d.rea Type: application/octet-stream Size: 270758 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bfs3d.usr Type: application/octet-stream Size: 2687 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Backstp.2323.o Type: application/octet-stream Size: 17576 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gdb.output Type: application/octet-stream Size: 2828 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler.out Type: application/octet-stream Size: 28178 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Fri Apr 9 09:53:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 16:53:00 +0200 Subject: [Nek5000-users] Seg. fault in running a backward facing step case. In-Reply-To: <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> Message-ID: Harish, when we try to exit the code with an error message the code crashes. You turned on OIFS (T IFCHAR) but you don't have enough memory available. I think you can just increase lelt to avoid this problem. Anyway the code should print out a reasonable err-msg and not a SEGFAULT! Stefan On Apr 9, 2010, at 4:33 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am trying to simulate flow in a 3D backward facing step (BFS) geometry. > > I have attached the *.box file and n2to3.in file that I use to create the > 3D geometry. For reference logfile, *.rea and *.usr files are attached. > The code is compiled with GNU compiler and OpenMPI. The code is compiled > for 16 processors and compiler.out file is attached as well. > > When I run the code, I get a seg. fault. After running the "gdb" tool on > the core.* file, I get the following output. I have attached the gdb > output file too. > =========================================================================== > Core was generated by `./nek5000'. > Program terminated with signal 11, Segmentation fault. > [New process 7652] > #0 0x0000000000488768 in chcopy_ () > =========================================================================== > > 3D BFS geometry has a wall at the bottom and symmetry b.c. at the top. But > if I change the top b.c. with wall the simulation works. For reference I > have attached the job output file. > > Initially, I thought the problem was with memory limitations on my cluster > for a bigger geometry. So I tried a smaller geometry, but I still kept > getting seg. faults. > > Help with solving this problem will be greatly appreciated. And sorry for > attaching so many files. > > Thanks, > > Harish._______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 9 10:52:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 17:52:34 +0200 Subject: [Nek5000-users] PN/PN and usrdiv In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <10CBF68F-D237-4238-8D5B-170445303491@lav.mavt.ethz.ch> Message-ID: <762CF1B8-9711-4072-92EC-77BCC2113972@lav.mavt.ethz.ch> Paul, I think know why. We should not multiply usrdiv with the mass matrix so just replace call col3 (h1,usrdiv,bm1,ntot1) call add2 (qtl,h1,ntot1) by call add2(qtl,usrdiv,ntot1) at the beginning of plan4(). Unfortunately I don't have the time to test this fix. Let me know if this works for you. Stefan On Apr 9, 2010, at 4:21 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Yes - I just checked and it's indeed not doing anything for > Pn-Pn. > > I'll get to this by the end of the afternoon... should take > minimal effort to repair I think. > > Sorry about this Markus. > > Paul > > > On Fri, 9 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> I have not used this feature for a while but usrdiv is used in plan4(). >> >> --- snip plan4.f --- >> 40 ! add user defined divergence to qtl >> 41 call col3 (h1,usrdiv,bm1,ntot1) >> 42 call add2 (qtl,h1,ntot1) >> --- snip plan4.f >> >> >> Stefan >> >> >> On Apr 9, 2010, at 1:49 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> since I switched the pressure scheme from P_N/P_N-2 to PN/PN, as recommended by an earlier email, I have divergence trouble (simulation crashes) at the outflow, were a stabilization technique as in examples "peris" and "jet" is in place (adding divergence via usrdiv). >>> I spent a long time trying to fix this (several test runs with increased outflow normal element length, increased divergence magnitude, mesh deformation to nozzle shape, which avoids crashing but has an adverse effect on the upstream flow,...) but I am becoming suspicious that usrdiv is just not used in PN/PN. >>> Is that true? If so, how to fix it? >>> >>> Thanks, >>> Markus >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 9 10:58:30 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 10:58:30 -0500 (CDT) Subject: [Nek5000-users] PN/PN and usrdiv In-Reply-To: <762CF1B8-9711-4072-92EC-77BCC2113972@lav.mavt.ethz.ch> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <10CBF68F-D237-4238-8D5B-170445303491@lav.mavt.ethz.ch> <762CF1B8-9711-4072-92EC-77BCC2113972@lav.mavt.ethz.ch> Message-ID: I'll check into it this afternoon... Paul On Fri, 9 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > I think know why. We should not multiply usrdiv with the mass matrix > > so just replace > > call col3 (h1,usrdiv,bm1,ntot1) > call add2 (qtl,h1,ntot1) > > by > > call add2(qtl,usrdiv,ntot1) > > at the beginning of plan4(). > > Unfortunately I don't have the time to test this fix. > > Let me know if this works for you. > Stefan > > > > On Apr 9, 2010, at 4:21 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> >> Yes - I just checked and it's indeed not doing anything for >> Pn-Pn. >> >> I'll get to this by the end of the afternoon... should take >> minimal effort to repair I think. >> >> Sorry about this Markus. >> >> Paul >> >> >> On Fri, 9 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> I have not used this feature for a while but usrdiv is used in plan4(). >>> >>> --- snip plan4.f --- >>> 40 ! add user defined divergence to qtl >>> 41 call col3 (h1,usrdiv,bm1,ntot1) >>> 42 call add2 (qtl,h1,ntot1) >>> --- snip plan4.f >>> >>> >>> Stefan >>> >>> >>> On Apr 9, 2010, at 1:49 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi, >>>> >>>> since I switched the pressure scheme from P_N/P_N-2 to PN/PN, as recommended by an earlier email, I have divergence trouble (simulation crashes) at the outflow, were a stabilization technique as in examples "peris" and "jet" is in place (adding divergence via usrdiv). >>>> I spent a long time trying to fix this (several test runs with increased outflow normal element length, increased divergence magnitude, mesh deformation to nozzle shape, which avoids crashing but has an adverse effect on the upstream flow,...) but I am becoming suspicious that usrdiv is just not used in PN/PN. >>>> Is that true? If so, how to fix it? >>>> >>>> Thanks, >>>> Markus >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 11:05:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 11:05:03 -0500 (CDT) Subject: [Nek5000-users] Seg. fault in running a backward facing step case. In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> Message-ID: Hi Stefan, Thanks for your reply. Compiling with with a larger lelt and OIFS on the code worked. So what I understand from your reply is that if OIFS is ON the code requires more memory and it should be compiled with more lelt rather than the exact lelt=lelg/lp. Harish. On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > Harish, > > when we try to exit the code with an error message the code crashes. You turned on OIFS (T IFCHAR) but you don't have enough memory available. I think you can just increase lelt to avoid this problem. Anyway the code should print out a reasonable err-msg and not a SEGFAULT! > > > Stefan > > > > On Apr 9, 2010, at 4:33 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello, > > > > I am trying to simulate flow in a 3D backward facing step (BFS) geometry. > > > > I have attached the *.box file and n2to3.in file that I use to create the > > 3D geometry. For reference logfile, *.rea and *.usr files are attached. > > The code is compiled with GNU compiler and OpenMPI. The code is compiled > > for 16 processors and compiler.out file is attached as well. > > > > When I run the code, I get a seg. fault. After running the "gdb" tool on > > the core.* file, I get the following output. I have attached the gdb > > output file too. > > =========================================================================== > > Core was generated by `./nek5000'. > > Program terminated with signal 11, Segmentation fault. > > [New process 7652] > > #0 0x0000000000488768 in chcopy_ () > > =========================================================================== > > > > 3D BFS geometry has a wall at the bottom and symmetry b.c. at the top. But > > if I change the top b.c. with wall the simulation works. For reference I > > have attached the job output file. > > > > Initially, I thought the problem was with memory limitations on my cluster > > for a bigger geometry. So I tried a smaller geometry, but I still kept > > getting seg. faults. > > > > Help with solving this problem will be greatly appreciated. And sorry for > > attaching so many files. > > > > Thanks, > > > > Harish._______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 11:06:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 18:06:58 +0200 Subject: [Nek5000-users] Seg. fault in running a backward facing step case. In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> Message-ID: <09BA9955-3527-495B-A548-1AEE7748B5F5@lav.mavt.ethz.ch> Yes that's true. I'll discuss with the other developers how this can be improved. Also we're working on a fix to avoid the SEGFAULT. Stefan On Apr 9, 2010, at 6:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > Thanks for your reply. Compiling with with a larger lelt and OIFS on the code worked. > > So what I understand from your reply is that if OIFS is ON the code requires more memory > and it should be compiled with more lelt rather than the exact lelt=lelg/lp. > > Harish. > > > On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > >> Harish, >> >> when we try to exit the code with an error message the code crashes. You turned on OIFS (T IFCHAR) but you don't have enough memory available. I think you can just increase lelt to avoid this problem. Anyway the code should print out a reasonable err-msg and not a SEGFAULT! >> >> >> Stefan >> >> >> >> On Apr 9, 2010, at 4:33 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello, >>> >>> I am trying to simulate flow in a 3D backward facing step (BFS) geometry. >>> >>> I have attached the *.box file and n2to3.in file that I use to create the >>> 3D geometry. For reference logfile, *.rea and *.usr files are attached. >>> The code is compiled with GNU compiler and OpenMPI. The code is compiled >>> for 16 processors and compiler.out file is attached as well. >>> >>> When I run the code, I get a seg. fault. After running the "gdb" tool on >>> the core.* file, I get the following output. I have attached the gdb >>> output file too. >>> =========================================================================== >>> Core was generated by `./nek5000'. >>> Program terminated with signal 11, Segmentation fault. >>> [New process 7652] >>> #0 0x0000000000488768 in chcopy_ () >>> =========================================================================== >>> >>> 3D BFS geometry has a wall at the bottom and symmetry b.c. at the top. But >>> if I change the top b.c. with wall the simulation works. For reference I >>> have attached the job output file. >>> >>> Initially, I thought the problem was with memory limitations on my cluster >>> for a bigger geometry. So I tried a smaller geometry, but I still kept >>> getting seg. faults. >>> >>> Help with solving this problem will be greatly appreciated. And sorry for >>> attaching so many files. >>> >>> Thanks, >>> >>> Harish._______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 9 11:12:13 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 11:12:13 -0500 (CDT) Subject: [Nek5000-users] Seg. fault in running a backward facing step case. In-Reply-To: <09BA9955-3527-495B-A548-1AEE7748B5F5@lav.mavt.ethz.ch> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> <09BA9955-3527-495B-A548-1AEE7748B5F5@lav.mavt.ethz.ch> Message-ID: Thanks for the help!! Harish On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > Yes that's true. I'll discuss with the other developers how this can be improved. Also we're working on a fix to avoid the SEGFAULT. > > Stefan > > > On Apr 9, 2010, at 6:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Stefan, > > > > Thanks for your reply. Compiling with with a larger lelt and OIFS on the code worked. > > > > So what I understand from your reply is that if OIFS is ON the code requires more memory > > and it should be compiled with more lelt rather than the exact lelt=lelg/lp. > > > > Harish. > > > > > > On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > > > >> Harish, > >> > >> when we try to exit the code with an error message the code crashes. You turned on OIFS (T IFCHAR) but you don't have enough memory available. I think you can just increase lelt to avoid this problem. Anyway the code should print out a reasonable err-msg and not a SEGFAULT! > >> > >> > >> Stefan > >> > >> > >> > >> On Apr 9, 2010, at 4:33 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hello, > >>> > >>> I am trying to simulate flow in a 3D backward facing step (BFS) geometry. > >>> > >>> I have attached the *.box file and n2to3.in file that I use to create the > >>> 3D geometry. For reference logfile, *.rea and *.usr files are attached. > >>> The code is compiled with GNU compiler and OpenMPI. The code is compiled > >>> for 16 processors and compiler.out file is attached as well. > >>> > >>> When I run the code, I get a seg. fault. After running the "gdb" tool on > >>> the core.* file, I get the following output. I have attached the gdb > >>> output file too. > >>> =========================================================================== > >>> Core was generated by `./nek5000'. > >>> Program terminated with signal 11, Segmentation fault. > >>> [New process 7652] > >>> #0 0x0000000000488768 in chcopy_ () > >>> =========================================================================== > >>> > >>> 3D BFS geometry has a wall at the bottom and symmetry b.c. at the top. But > >>> if I change the top b.c. with wall the simulation works. For reference I > >>> have attached the job output file. > >>> > >>> Initially, I thought the problem was with memory limitations on my cluster > >>> for a bigger geometry. So I tried a smaller geometry, but I still kept > >>> getting seg. faults. > >>> > >>> Help with solving this problem will be greatly appreciated. And sorry for > >>> attaching so many files. > >>> > >>> Thanks, > >>> > >>> Harish._______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 11:30:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 18:30:20 +0200 Subject: [Nek5000-users] Seg. fault in running a backward facing step case. In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> <09BA9955-3527-495B-A548-1AEE7748B5F5@lav.mavt.ethz.ch> Message-ID: For the moment you're ok if: TORDER=2, LORDER=3, LELT=NELT/NP + 1 TORDER=2, LORDER=3, LELT= (3/2) * NELT/NP + 1 TORDER=3, LORDER=3, LELT= (4/3) * NELT/NP + 1 hth, Stefan On Apr 9, 2010, at 6:12 PM, nek5000-users at lists.mcs.anl.gov wrote: > Thanks for the help!! > > Harish > > On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > >> Yes that's true. I'll discuss with the other developers how this can be improved. Also we're working on a fix to avoid the SEGFAULT. >> >> Stefan >> >> >> On Apr 9, 2010, at 6:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Stefan, >>> >>> Thanks for your reply. Compiling with with a larger lelt and OIFS on the code worked. >>> >>> So what I understand from your reply is that if OIFS is ON the code requires more memory >>> and it should be compiled with more lelt rather than the exact lelt=lelg/lp. >>> >>> Harish. >>> >>> >>> On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Harish, >>>> >>>> when we try to exit the code with an error message the code crashes. You turned on OIFS (T IFCHAR) but you don't have enough memory available. I think you can just increase lelt to avoid this problem. Anyway the code should print out a reasonable err-msg and not a SEGFAULT! >>>> >>>> >>>> Stefan >>>> >>>> >>>> >>>> On Apr 9, 2010, at 4:33 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hello, >>>>> >>>>> I am trying to simulate flow in a 3D backward facing step (BFS) geometry. >>>>> >>>>> I have attached the *.box file and n2to3.in file that I use to create the >>>>> 3D geometry. For reference logfile, *.rea and *.usr files are attached. >>>>> The code is compiled with GNU compiler and OpenMPI. The code is compiled >>>>> for 16 processors and compiler.out file is attached as well. >>>>> >>>>> When I run the code, I get a seg. fault. After running the "gdb" tool on >>>>> the core.* file, I get the following output. I have attached the gdb >>>>> output file too. >>>>> =========================================================================== >>>>> Core was generated by `./nek5000'. >>>>> Program terminated with signal 11, Segmentation fault. >>>>> [New process 7652] >>>>> #0 0x0000000000488768 in chcopy_ () >>>>> =========================================================================== >>>>> >>>>> 3D BFS geometry has a wall at the bottom and symmetry b.c. at the top. But >>>>> if I change the top b.c. with wall the simulation works. For reference I >>>>> have attached the job output file. >>>>> >>>>> Initially, I thought the problem was with memory limitations on my cluster >>>>> for a bigger geometry. So I tried a smaller geometry, but I still kept >>>>> getting seg. faults. >>>>> >>>>> Help with solving this problem will be greatly appreciated. And sorry for >>>>> attaching so many files. >>>>> >>>>> Thanks, >>>>> >>>>> Harish._______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 9 11:57:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 18:57:55 +0200 Subject: [Nek5000-users] Seg. fault in running a backward facing step case. In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> <09BA9955-3527-495B-A548-1AEE7748B5F5@lav.mavt.ethz.ch> Message-ID: <179E0205-14F8-4EA4-9FE8-1DB4FE7CC8A0@lav.mavt.ethz.ch> Ok I have just fixed the SEGFAULT in the latest release. Stefan On Apr 9, 2010, at 6:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > For the moment you're ok if: > > TORDER=2, LORDER=3, LELT=NELT/NP + 1 > TORDER=2, LORDER=3, LELT= (3/2) * NELT/NP + 1 > TORDER=3, LORDER=3, LELT= (4/3) * NELT/NP + 1 > > hth, > Stefan > > On Apr 9, 2010, at 6:12 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Thanks for the help!! >> >> Harish >> >> On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: >> >>> Yes that's true. I'll discuss with the other developers how this can be improved. Also we're working on a fix to avoid the SEGFAULT. >>> >>> Stefan >>> >>> >>> On Apr 9, 2010, at 6:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi Stefan, >>>> >>>> Thanks for your reply. Compiling with with a larger lelt and OIFS on the code worked. >>>> >>>> So what I understand from your reply is that if OIFS is ON the code requires more memory >>>> and it should be compiled with more lelt rather than the exact lelt=lelg/lp. >>>> >>>> Harish. >>>> >>>> >>>> On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Harish, >>>>> >>>>> when we try to exit the code with an error message the code crashes. You turned on OIFS (T IFCHAR) but you don't have enough memory available. I think you can just increase lelt to avoid this problem. Anyway the code should print out a reasonable err-msg and not a SEGFAULT! >>>>> >>>>> >>>>> Stefan >>>>> >>>>> >>>>> >>>>> On Apr 9, 2010, at 4:33 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I am trying to simulate flow in a 3D backward facing step (BFS) geometry. >>>>>> >>>>>> I have attached the *.box file and n2to3.in file that I use to create the >>>>>> 3D geometry. For reference logfile, *.rea and *.usr files are attached. >>>>>> The code is compiled with GNU compiler and OpenMPI. The code is compiled >>>>>> for 16 processors and compiler.out file is attached as well. >>>>>> >>>>>> When I run the code, I get a seg. fault. After running the "gdb" tool on >>>>>> the core.* file, I get the following output. I have attached the gdb >>>>>> output file too. >>>>>> =========================================================================== >>>>>> Core was generated by `./nek5000'. >>>>>> Program terminated with signal 11, Segmentation fault. >>>>>> [New process 7652] >>>>>> #0 0x0000000000488768 in chcopy_ () >>>>>> =========================================================================== >>>>>> >>>>>> 3D BFS geometry has a wall at the bottom and symmetry b.c. at the top. But >>>>>> if I change the top b.c. with wall the simulation works. For reference I >>>>>> have attached the job output file. >>>>>> >>>>>> Initially, I thought the problem was with memory limitations on my cluster >>>>>> for a bigger geometry. So I tried a smaller geometry, but I still kept >>>>>> getting seg. faults. >>>>>> >>>>>> Help with solving this problem will be greatly appreciated. And sorry for >>>>>> attaching so many files. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Harish._______________________________________________ >>>>>> Nek5000-users mailing list >>>>>> Nek5000-users at lists.mcs.anl.gov >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 9 12:12:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 12:12:09 -0500 (CDT) Subject: [Nek5000-users] Seg. fault in running a backward facing step case. In-Reply-To: <179E0205-14F8-4EA4-9FE8-1DB4FE7CC8A0@lav.mavt.ethz.ch> References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> <09BA9955-3527-495B-A548-1AEE7748B5F5@lav.mavt.ethz.ch> <179E0205-14F8-4EA4-9FE8-1DB4FE7CC8A0@lav.mavt.ethz.ch> Message-ID: Hi Stefan, Thanks for all your help. I will download the latest release and test it. Thanks, Harish On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > Ok I have just fixed the SEGFAULT in the latest release. > > Stefan > > > On Apr 9, 2010, at 6:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > For the moment you're ok if: > > > > TORDER=2, LORDER=3, LELT=NELT/NP + 1 > > TORDER=2, LORDER=3, LELT= (3/2) * NELT/NP + 1 > > TORDER=3, LORDER=3, LELT= (4/3) * NELT/NP + 1 > > > > hth, > > Stefan > > > > On Apr 9, 2010, at 6:12 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Thanks for the help!! > >> > >> Harish > >> > >> On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Yes that's true. I'll discuss with the other developers how this can be improved. Also we're working on a fix to avoid the SEGFAULT. > >>> > >>> Stefan > >>> > >>> > >>> On Apr 9, 2010, at 6:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>> > >>>> Hi Stefan, > >>>> > >>>> Thanks for your reply. Compiling with with a larger lelt and OIFS on the code worked. > >>>> > >>>> So what I understand from your reply is that if OIFS is ON the code requires more memory > >>>> and it should be compiled with more lelt rather than the exact lelt=lelg/lp. > >>>> > >>>> Harish. > >>>> > >>>> > >>>> On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Harish, > >>>>> > >>>>> when we try to exit the code with an error message the code crashes. You turned on OIFS (T IFCHAR) but you don't have enough memory available. I think you can just increase lelt to avoid this problem. Anyway the code should print out a reasonable err-msg and not a SEGFAULT! > >>>>> > >>>>> > >>>>> Stefan > >>>>> > >>>>> > >>>>> > >>>>> On Apr 9, 2010, at 4:33 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>>> > >>>>>> Hello, > >>>>>> > >>>>>> I am trying to simulate flow in a 3D backward facing step (BFS) geometry. > >>>>>> > >>>>>> I have attached the *.box file and n2to3.in file that I use to create the > >>>>>> 3D geometry. For reference logfile, *.rea and *.usr files are attached. > >>>>>> The code is compiled with GNU compiler and OpenMPI. The code is compiled > >>>>>> for 16 processors and compiler.out file is attached as well. > >>>>>> > >>>>>> When I run the code, I get a seg. fault. After running the "gdb" tool on > >>>>>> the core.* file, I get the following output. I have attached the gdb > >>>>>> output file too. > >>>>>> =========================================================================== > >>>>>> Core was generated by `./nek5000'. > >>>>>> Program terminated with signal 11, Segmentation fault. > >>>>>> [New process 7652] > >>>>>> #0 0x0000000000488768 in chcopy_ () > >>>>>> =========================================================================== > >>>>>> > >>>>>> 3D BFS geometry has a wall at the bottom and symmetry b.c. at the top. But > >>>>>> if I change the top b.c. with wall the simulation works. For reference I > >>>>>> have attached the job output file. > >>>>>> > >>>>>> Initially, I thought the problem was with memory limitations on my cluster > >>>>>> for a bigger geometry. So I tried a smaller geometry, but I still kept > >>>>>> getting seg. faults. > >>>>>> > >>>>>> Help with solving this problem will be greatly appreciated. And sorry for > >>>>>> attaching so many files. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Harish._______________________________________________ > >>>>>> Nek5000-users mailing list > >>>>>> Nek5000-users at lists.mcs.anl.gov > >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>>> > >>>>> _______________________________________________ > >>>>> Nek5000-users mailing list > >>>>> Nek5000-users at lists.mcs.anl.gov > >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>>> > >>>> _______________________________________________ > >>>> Nek5000-users mailing list > >>>> Nek5000-users at lists.mcs.anl.gov > >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>> > >>> _______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 12:43:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 12:43:15 -0500 (CDT) Subject: [Nek5000-users] Seg. fault in running a backward facing step case. In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <7b2080d07424b289a4bf313925229643.squirrel@webmail.uic.edu> <09BA9955-3527-495B-A548-1AEE7748B5F5@lav.mavt.ethz.ch> Message-ID: I typically set lorder=4 On Fri, 9 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > For the moment you're ok if: > > TORDER=2, LORDER=3, LELT=NELT/NP + 1 > TORDER=2, LORDER=3, LELT= (3/2) * NELT/NP + 1 > TORDER=3, LORDER=3, LELT= (4/3) * NELT/NP + 1 > > hth, > Stefan > > On Apr 9, 2010, at 6:12 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Thanks for the help!! >> >> Harish >> >> On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: >> >>> Yes that's true. I'll discuss with the other developers how this can be improved. Also we're working on a fix to avoid the SEGFAULT. >>> >>> Stefan >>> >>> >>> On Apr 9, 2010, at 6:05 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi Stefan, >>>> >>>> Thanks for your reply. Compiling with with a larger lelt and OIFS on the code worked. >>>> >>>> So what I understand from your reply is that if OIFS is ON the code requires more memory >>>> and it should be compiled with more lelt rather than the exact lelt=lelg/lp. >>>> >>>> Harish. >>>> >>>> >>>> On Fri, 9 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Harish, >>>>> >>>>> when we try to exit the code with an error message the code crashes. You turned on OIFS (T IFCHAR) but you don't have enough memory available. I think you can just increase lelt to avoid this problem. Anyway the code should print out a reasonable err-msg and not a SEGFAULT! >>>>> >>>>> >>>>> Stefan >>>>> >>>>> >>>>> >>>>> On Apr 9, 2010, at 4:33 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I am trying to simulate flow in a 3D backward facing step (BFS) geometry. >>>>>> >>>>>> I have attached the *.box file and n2to3.in file that I use to create the >>>>>> 3D geometry. For reference logfile, *.rea and *.usr files are attached. >>>>>> The code is compiled with GNU compiler and OpenMPI. The code is compiled >>>>>> for 16 processors and compiler.out file is attached as well. >>>>>> >>>>>> When I run the code, I get a seg. fault. After running the "gdb" tool on >>>>>> the core.* file, I get the following output. I have attached the gdb >>>>>> output file too. >>>>>> =========================================================================== >>>>>> Core was generated by `./nek5000'. >>>>>> Program terminated with signal 11, Segmentation fault. >>>>>> [New process 7652] >>>>>> #0 0x0000000000488768 in chcopy_ () >>>>>> =========================================================================== >>>>>> >>>>>> 3D BFS geometry has a wall at the bottom and symmetry b.c. at the top. But >>>>>> if I change the top b.c. with wall the simulation works. For reference I >>>>>> have attached the job output file. >>>>>> >>>>>> Initially, I thought the problem was with memory limitations on my cluster >>>>>> for a bigger geometry. So I tried a smaller geometry, but I still kept >>>>>> getting seg. faults. >>>>>> >>>>>> Help with solving this problem will be greatly appreciated. And sorry for >>>>>> attaching so many files. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Harish._______________________________________________ >>>>>> Nek5000-users mailing list >>>>>> Nek5000-users at lists.mcs.anl.gov >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 12:44:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 12:44:23 -0500 (CDT) Subject: [Nek5000-users] question about comilers In-Reply-To: <4BBF580A.4000905@vt.edu> References: <4BBEA6F7.5060003@vt.edu> <4BBF580A.4000905@vt.edu> Message-ID: Hi Mark, I don't know if anyone else has encountered this... I'll try to take a look as well. Paul On Fri, 9 Apr 2010, Mark Paul wrote: > > Hi Paul, > > Thanks -- our most immediate issue is postx. I can't seem to > get postx to compile on a mac using gfortran and gcc. The > compile crashes at xdriver.c with the error: > > gcc -c -O2 xdriver.c > xdriver.c:14:16: error: icon: No such file or directory > xdriver.c: In function ?SetUpEnv?: > xdriver.c:1266: error: ?icon_bits? undeclared (first use in this function) > xdriver.c:1266: error: (Each undeclared identifier is reported only once > xdriver.c:1266: error: for each function it appears in.) > xdriver.c:1266: error: ?icon_width? undeclared (first use in this function) > xdriver.c:1266: error: ?icon_height? undeclared (first use in this function) > xdriver.c: In function ?TypeChar?: > xdriver.c:1628: warning: comparison is always true due to limited range of > data type > xdriver.c: In function ?error?: > xdriver.c:1748: warning: format not a string literal and no format arguments > make: *** [xdriver.o] Error 1 > > We still use postx quite a lot and it is important for us to be able > to compile and use it on multiple machines making the free compiler > an important part. Any thoughts on this? > > Thanks, > > Mark > > On 4/9/10 4:25 AM, Paul Fischer wrote: >> >> Hi Mark, >> >> g95 + gcc I think is fine... cc'g the users list >> >> I believe the builds should just go through w/ the current >> repo version of the code. >> >> Paul >> >> On Fri, 9 Apr 2010, Mark Paul wrote: >> >>> >>> Hi Paul, >>> >>> Can you recommend a free set of compilers we can use on mac os x >>> snow leopard and for linux to run nekton, postx, and prex? We have >>> used pgi in the past but it is getting too pricey and always seems >>> to need an expensive upgrade to be supported on current os >>> distributions etc. >>> >>> This would just be for small jobs and post-processing. I was going >>> to try gcc and gfortran but wanted to get your thoughts on this >>> before hacking around too much. >>> >>> Thanks, >>> >>> Mark >>> >>> > From nek5000-users at lists.mcs.anl.gov Fri Apr 9 12:50:01 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 19:50:01 +0200 Subject: [Nek5000-users] question about comilers In-Reply-To: References: <4BBEA6F7.5060003@vt.edu> <4BBF580A.4000905@vt.edu> Message-ID: I just tested it with gfortran/gcc 4.3.3 and it compiled w/o a problem. What version did you use? Stefan On Apr 9, 2010, at 7:44 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Mark, > I don't know if anyone else has encountered this... > > I'll try to take a look as well. > > Paul > > > On Fri, 9 Apr 2010, Mark Paul wrote: > >> >> Hi Paul, >> >> Thanks -- our most immediate issue is postx. I can't seem to >> get postx to compile on a mac using gfortran and gcc. The >> compile crashes at xdriver.c with the error: >> >> gcc -c -O2 xdriver.c >> xdriver.c:14:16: error: icon: No such file or directory >> xdriver.c: In function ?SetUpEnv?: >> xdriver.c:1266: error: ?icon_bits? undeclared (first use in this function) >> xdriver.c:1266: error: (Each undeclared identifier is reported only once >> xdriver.c:1266: error: for each function it appears in.) >> xdriver.c:1266: error: ?icon_width? undeclared (first use in this function) >> xdriver.c:1266: error: ?icon_height? undeclared (first use in this function) >> xdriver.c: In function ?TypeChar?: >> xdriver.c:1628: warning: comparison is always true due to limited range of data type >> xdriver.c: In function ?error?: >> xdriver.c:1748: warning: format not a string literal and no format arguments >> make: *** [xdriver.o] Error 1 >> >> We still use postx quite a lot and it is important for us to be able >> to compile and use it on multiple machines making the free compiler >> an important part. Any thoughts on this? >> >> Thanks, >> >> Mark >> >> On 4/9/10 4:25 AM, Paul Fischer wrote: >>> Hi Mark, >>> g95 + gcc I think is fine... cc'g the users list >>> I believe the builds should just go through w/ the current >>> repo version of the code. >>> Paul >>> On Fri, 9 Apr 2010, Mark Paul wrote: >>>> Hi Paul, >>>> Can you recommend a free set of compilers we can use on mac os x >>>> snow leopard and for linux to run nekton, postx, and prex? We have >>>> used pgi in the past but it is getting too pricey and always seems >>>> to need an expensive upgrade to be supported on current os >>>> distributions etc. >>>> This would just be for small jobs and post-processing. I was going >>>> to try gcc and gfortran but wanted to get your thoughts on this >>>> before hacking around too much. >>>> Thanks, >>>> Mark > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 9 12:55:26 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 19:55:26 +0200 Subject: [Nek5000-users] question about comilers In-Reply-To: References: <4BBEA6F7.5060003@vt.edu> <4BBF580A.4000905@vt.edu> Message-ID: <682CDCDF-443E-4185-B0F4-0693088D0D79@lav.mavt.ethz.ch> It looks like the compiler is missing the include file icon > gcc -c -O2 xdriver.c > xdriver.c:14:16: error: icon: No such file or directory Also, what revision of the tools are you using? Stefan On Apr 9, 2010, at 7:50 PM, nek5000-users at lists.mcs.anl.gov wrote: > I just tested it with gfortran/gcc 4.3.3 and it compiled w/o a problem. > What version did you use? > > Stefan From nek5000-users at lists.mcs.anl.gov Fri Apr 9 15:33:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 9 Apr 2010 15:33:48 -0500 (CDT) Subject: [Nek5000-users] PN/PN and usrdiv In-Reply-To: References: <134916948.99691269729291839.JavaMail.root@neo-mail-3> <4BB0B22C.9030903@vt.edu> <4BBF1443.4090501@vt.edu> <10CBF68F-D237-4238-8D5B-170445303491@lav.mavt.ethz.ch> <762CF1B8-9711-4072-92EC-77BCC2113972@lav.mavt.ethz.ch> Message-ID: In addition to the issue that Stefan identified, it turns out that the set_outflow_dist() routine in the .usr file was dependent on zm2 (z coords on mesh2), which defined only for Pn-Pn-2. I've updated coef.f so that xm2 ym2 and zm2 are now defined for both formulations and it seems that the outflow conditions are now working. Paul On Fri, 9 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > I'll check into it this afternoon... > > Paul > > > On Fri, 9 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Paul, >> >> I think know why. We should not multiply usrdiv with the mass matrix >> >> so just replace >> >> call col3 (h1,usrdiv,bm1,ntot1) >> call add2 (qtl,h1,ntot1) >> >> by >> >> call add2(qtl,usrdiv,ntot1) >> >> at the beginning of plan4(). >> >> Unfortunately I don't have the time to test this fix. >> >> Let me know if this works for you. >> Stefan >> >> >> >> On Apr 9, 2010, at 4:21 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> >>> Yes - I just checked and it's indeed not doing anything for >>> Pn-Pn. >>> >>> I'll get to this by the end of the afternoon... should take >>> minimal effort to repair I think. >>> >>> Sorry about this Markus. >>> >>> Paul >>> >>> >>> On Fri, 9 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> I have not used this feature for a while but usrdiv is used in plan4(). >>>> >>>> --- snip plan4.f --- >>>> 40 ! add user defined divergence to qtl >>>> 41 call col3 (h1,usrdiv,bm1,ntot1) >>>> 42 call add2 (qtl,h1,ntot1) >>>> --- snip plan4.f >>>> >>>> >>>> Stefan >>>> >>>> >>>> On Apr 9, 2010, at 1:49 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi, >>>>> >>>>> since I switched the pressure scheme from P_N/P_N-2 to PN/PN, as >>>>> recommended by an earlier email, I have divergence trouble (simulation >>>>> crashes) at the outflow, were a stabilization technique as in examples >>>>> "peris" and "jet" is in place (adding divergence via usrdiv). >>>>> I spent a long time trying to fix this (several test runs with increased >>>>> outflow normal element length, increased divergence magnitude, mesh >>>>> deformation to nozzle shape, which avoids crashing but has an adverse >>>>> effect on the upstream flow,...) but I am becoming suspicious that >>>>> usrdiv is just not used in PN/PN. >>>>> Is that true? If so, how to fix it? >>>>> >>>>> Thanks, >>>>> Markus >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sat Apr 10 04:43:24 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 10 Apr 2010 04:43:24 -0500 (CDT) Subject: [Nek5000-users] Representing Curved Side in any plane In-Reply-To: <1950630819.4983791270762806762.JavaMail.root@neo-mail-3> References: <1950630819.4983791270762806762.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, Markus, There will of course be a threshold, as there are limits to the amount of acceptable deformation. I don't know how best to advise you, other than to start with something as simple as possible, so you can gain some familiarity. You should also note that you need to deform all shared internal edges (typically 4, but could be more or less) in the same way if your mesh is to be consistent. Ideally, if you had a way to generate 20-noded brick elements then these midside nodes would correspond to the 12 edge vertices (in some funny ordering). If I have an idea of what you're after I might be able to help you further. Paul On Thu, 8 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Hi Paul, > > > > We tried a few simple geometries with the new midpoint feature and did have > > some success, however we are also experiencing a new learning curve with the > > feature and thought you could shine some light on it. > > > > We tried with only one element and have been successful.?? We??then tried with > > many elements, including all midpoints in the curved side section, and we > > received the "vanishing jacobian" error. Next, we tried removing from the curved > > side section; internal edges. So, any midpoints on edges that were "interior" to the > > geometry.?? My best way to explain this would be midpoints which lie on edges that > > ??do not see a boundary (meaning the edge is shared by elements on all sides.)?? This > > ??left us with only midpoints on the outer surface of the geometry, which we were able > > to deform quite nicely. However, we did reach a threshold at which point > > we got the "vanishing jacobian" again. > > > > So this brings up two questions: > > > > 1.???? Is there no support for??internal edges, meaning only midpoints on the surface > > of the geometry can be deformed? (If so, I think that is not an issue but good > > information to have). > > > > 2.?? Is there a threshold??distance??from the midpoint to the undeformed edge??for it > > to work??? Markus ran a??case where??the following worked: > > > > 10 ??1 ?? 0.75000 ?? ?? -0.090000 ?? ?? ??0.750000 ?? ?? ?? 0.00000 ?? ?? ?? 0.00000?????????????? m > ?? 9 ??3 ?? 0.75000 ?? ?? -0.090000 ?? ?? ??0.750000 ?? ?? ?? 0.00000???????????? 0.00000 ?? ???????? m > > > > But, below??did not.?????????? > > 10 ??1 ?? 0.75000 ?? ?? -0.100000 ?? ?? ??0.750000 ?? ?? ?? 0.00000 ?? ?? ?? 0.00000???????????? m > ?? 9 ??3 ?? 0.75000 ?? ?? -0.100000 ?? ?? ??0.750000 ?? ?? ?? 0.00000??????????????0.00000 ?? ?????? m > > > > Thanks for any insight you can provide with this and the new feature! > > > > Regards, > > Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, April 5, 2010 10:17:21 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] Representing Curved Side in any plane > > > > > Hey Paul, > > > > Sounds great! And I think this is exactly what we needed! We will try it tomorrow. > > > > Thanks again, > > Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, April 5, 2010 9:29:33 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] Representing Curved Side in any plane > > Hi, I've just added the midside-node support to the current svn repo for nek. > > > > Sorry - I thought I had upgraded this in October but apparently had not committed to > > the repo then. Hopefully all should work -- I retested my original benchmark w/ this new > > version and it is functioning. Please let me know if this now works for you. > > You should be able to modify any one of the 12 edges. > > > > Paul > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Sun Apr 11 18:30:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 01:30:34 +0200 Subject: [Nek5000-users] Possible bug "navier1.f" In-Reply-To: References: <4BBEA6F7.5060003@vt.edu> Message-ID: <1271028634.8715.288.camel@localhost.localdomain> Hello all, I came across a couple of places where an argument is missing. CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1) ^ "/home/fmuldoo/nek5_svn/trunk/nek/navier1.f", Line = 2548, Column = 7: WARNING: Procedure "MULTD" is defined at line 564 (/home/fmuldoo/nek5_svn/trunk/nek/navier1.f) and has 7 dummy argument(s). This reference has 6 actual argument(s) specified. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Sun Apr 11 19:15:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 11 Apr 2010 19:15:50 -0500 (CDT) Subject: [Nek5000-users] =?utf-8?q?Possible_bug_=22navier1=2Ef=22?= In-Reply-To: <1271028634.8715.288.camel@localhost.localdomain> References: <4BBEA6F7.5060003@vt.edu> <1271028634.8715.288.camel@localhost.localdomain> Message-ID: Thanks Frank - You're correct. I appears to be in a test routine that is never used and probably was not updated. I deleted it so it will get taken care of in the next round. Paul On Mon, 12 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, I came across a couple of places where an argument is missing. CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1) ^ "/home/fmuldoo/nek5_svn/trunk/nek/navier1.f", Line = 2548, Column = 7: WARNING: Procedure "MULTD" is defined at line 564 (/home/fmuldoo/nek5_svn/trunk/nek/navier1.f) and has 7 dummy argument(s). This reference has 6 actual argument(s) specified. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 12 03:04:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 10:04:00 +0200 Subject: [Nek5000-users] possible bug Message-ID: <1271059440.8715.293.camel@localhost.localdomain> Hello all, I came across a possible problem with inconsistent data types. call mpi_copy_double_precision ( data1, data2, n, ierror ) ^ "/home/fmuldoo/nek5_svn/trunk/nek/mpi_dummy.f", Line = 837, Column = 42: WARNING: Procedure "MPI_COPY_DOUBLE_PRECISION" is defined at line 420 (/home/fmuldoo/nek5_svn/trunk/nek/mpi_dummy.f). The actual argument type does not agree with the type of dummy argument "DATA1". Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 12 03:28:26 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 10:28:26 +0200 Subject: [Nek5000-users] possible bug In-Reply-To: <1271059440.8715.293.camel@localhost.localdomain> References: <1271059440.8715.293.camel@localhost.localdomain> Message-ID: <51888372-87A9-4B02-A09B-CF3EE751E6FA@lav.mavt.ethz.ch> Hi Frank, I am sure you'll find more things in mpi_dummy.f which are not consistent. It's just an ugly hack to run NEK in serial w/o using a MPI library. However only a few routines in the dummy lib are actually used. Your compiler is right, the data types to not agree here. However you're just passing the arguments to another routines so it should be ok even though the datatypes do not match. You can think of it as passing a pointer. Stefan On Apr 12, 2010, at 10:04 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I came across a possible problem with inconsistent data types. > > call mpi_copy_double_precision ( data1, data2, n, ierror ) > ^ > "/home/fmuldoo/nek5_svn/trunk/nek/mpi_dummy.f", Line = 837, Column = 42: > WARNING: Procedure "MPI_COPY_DOUBLE_PRECISION" is defined at line 420 > (/home/fmuldoo/nek5_svn/trunk/nek/mpi_dummy.f). The actual argument > type does not agree with the type of dummy argument "DATA1". > > Cheers, > Frank > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 12 03:50:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 10:50:23 +0200 Subject: [Nek5000-users] output files Message-ID: <1271062223.8715.313.camel@localhost.localdomain> Hello all, Is there a description of the format of the output files? Are there two types of output files, one for restarting, the other for visualization? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 12 04:03:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 11:03:55 +0200 Subject: [Nek5000-users] time-series of files in visit w/o mesh Message-ID: <4BC2E1FB.2050705@mech.kth.se> Hi, First, I would just like to say that I am impressed by you guys (Paul and Stefan). You are incredible efficient in helping people out with their problems! This is a rather easy question I guess: How would you do in Visit when you have a time-varying data base without the mesh in every file (i.e. only in the first file)? Best regards, Johan -- Johan Ohlsson Department of Mechanics, KTH SE-100 44, Stockholm, Sweden Phone: +46 8 7906876 E-mail: johan at mech.kth.se From nek5000-users at lists.mcs.anl.gov Mon Apr 12 04:07:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 11:07:34 +0200 Subject: [Nek5000-users] time-series of files in visit w/o mesh In-Reply-To: <4BC2E1FB.2050705@mech.kth.se> References: <4BC2E1FB.2050705@mech.kth.se> Message-ID: <322EABD5-55E6-4D2B-8E2D-24BEE79C8653@lav.mavt.ethz.ch> Hi Johan, there should be no problem if you have just the geometry in the first fld file. In fact that's the way to go because VisIt will cache the mesh in this case lowering the amount of data you have to read. Stefan On Apr 12, 2010, at 11:03 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > First, I would just like to say that I am impressed by you guys (Paul > and Stefan). You are incredible efficient in helping people out with > their problems! > > This is a rather easy question I guess: How would you do in Visit when > you have a time-varying data base without the mesh in every file (i.e. > only in the first file)? > > Best regards, > > Johan > > -- > Johan Ohlsson > Department of Mechanics, KTH > SE-100 44, Stockholm, Sweden > Phone: +46 8 7906876 > E-mail: johan at mech.kth.se > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 12 04:12:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 11:12:38 +0200 Subject: [Nek5000-users] output files In-Reply-To: <1271062223.8715.313.camel@localhost.localdomain> References: <1271062223.8715.313.camel@localhost.localdomain> Message-ID: <53C3F9AA-2F9F-46CA-B431-563F4E444BAC@lav.mavt.ethz.ch> Unfortunately there is no documentation of the data layout. Just led me know if you're interested into the layout details and I'll tell more. Typically we dump the data (fld files) on the GLL mesh. In this case you can use the data for restarts. In addition we provide the option to dump the data onto a regular mesh. This is just for visualization and cannot be used for a restart (the interpolation from uniform->GLL in unstable). hth, Stefan On Apr 12, 2010, at 10:50 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > Is there a description of the format of the output files? Are there two > types of output files, one for restarting, the other for > visualization? > > Cheers, > Frank > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 12 04:18:56 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 09:18:56 -0000 Subject: [Nek5000-users] output files In-Reply-To: <53C3F9AA-2F9F-46CA-B431-563F4E444BAC@lav.mavt.ethz.ch> References: <1271062223.8715.313.camel@localhost.localdomain> <53C3F9AA-2F9F-46CA-B431-563F4E444BAC@lav.mavt.ethz.ch> Message-ID: <1183932183.8715.320.camel@localhost.localdomain> On Mon, 2010-04-12 at 11:12 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Unfortunately there is no documentation of the data layout. Just led me know if you're interested into the layout details and I'll tell more. Hello Stefan, Yes, I'd be very interested in that, in particular for the case where the data is on the GLL nodes. Cheers, Frank > > Typically we dump the data (fld files) on the GLL mesh. In this case you can use the data for restarts. In addition we provide the option to dump the data onto a regular mesh. This is just for visualization and cannot be used for a restart (the interpolation from uniform->GLL in unstable). > > hth, > Stefan > > > On Apr 12, 2010, at 10:50 AM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > > > Is there a description of the format of the output files? Are there two > > types of output files, one for restarting, the other for > > visualization? > > > > Cheers, > > Frank > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 12 04:31:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 11:31:46 +0200 Subject: [Nek5000-users] output files In-Reply-To: <1183932183.8715.320.camel@localhost.localdomain> References: <1271062223.8715.313.camel@localhost.localdomain> <53C3F9AA-2F9F-46CA-B431-563F4E444BAC@lav.mavt.ethz.ch> <1183932183.8715.320.camel@localhost.localdomain> Message-ID: Check mfi() in ic.f. It should be pretty straightforward to understand what's going on and how the data layout look like. If you're not able to unravel how it works just let me know. Here is the basic layout: - The first 132 bytes are reserved for the HEADER. Here we store the number of elements, polynomial order, timestamp and the variable present in the fld file. - Followed by a 4 byte number to test if we need to swap the bytes or not (big vs. small endian). - Then we store the domain partitioning (global element ids for all elements present in this fld file) - Finally the data follows Stefan On Jul 9, 2007, at 12:03 AM, nek5000-users at lists.mcs.anl.gov wrote: > On Mon, 2010-04-12 at 11:12 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Unfortunately there is no documentation of the data layout. Just led me know if you're interested into the layout details and I'll tell more. > > Hello Stefan, > > Yes, I'd be very interested in that, in particular for the case where > the data is on the GLL nodes. > > Cheers, > Frank > >> >> Typically we dump the data (fld files) on the GLL mesh. In this case you can use the data for restarts. In addition we provide the option to dump the data onto a regular mesh. This is just for visualization and cannot be used for a restart (the interpolation from uniform->GLL in unstable). >> >> hth, >> Stefan >> >> >> On Apr 12, 2010, at 10:50 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >>> >>> Is there a description of the format of the output files? Are there two >>> types of output files, one for restarting, the other for >>> visualization? >>> >>> Cheers, >>> Frank >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 12 05:46:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 12:46:11 +0200 Subject: [Nek5000-users] Possible bug Message-ID: <1271069171.10936.31.camel@localhost.localdomain> Hello all, In "ic.f", line 2030 there is "real*4 wk(lwk)" in the declarations for subroutine "mfi_gets". However, at line 2489 there is "call mfi_gets(pm1,wk,lwk,.false.)" where "wk" is double precison. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 12 06:36:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 06:36:16 -0500 (CDT) Subject: [Nek5000-users] Possible bug In-Reply-To: <1271069171.10936.31.camel@localhost.localdomain> References: <1271069171.10936.31.camel@localhost.localdomain> Message-ID: Hi Frank, You'll find many such instances in nek, since we are only concerned with whether the space is allocated, and not so much about its type, which matters only at point of use (subject to caveats of sufficient space and proper byte alignment). In this particular case, wk is a work array used inside mfi_gets - only pm1 is returned as useful output. Paul On Mon, 12 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, In "ic.f", line 2030 there is "real*4 wk(lwk)" in the declarations for subroutine "mfi_gets". However, at line 2489 there is "call mfi_gets(pm1,wk,lwk,.false.)" where "wk" is double precison. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 12 07:27:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 14:27:00 +0200 Subject: [Nek5000-users] time-series of files in visit w/o mesh In-Reply-To: <322EABD5-55E6-4D2B-8E2D-24BEE79C8653@lav.mavt.ethz.ch> References: <4BC2E1FB.2050705@mech.kth.se> <322EABD5-55E6-4D2B-8E2D-24BEE79C8653@lav.mavt.ethz.ch> Message-ID: <4BC31194.4020203@mech.kth.se> Thanks Stefan, works perfect! Johan nek5000-users at lists.mcs.anl.gov wrote: > Hi Johan, > > there should be no problem if you have just the geometry in the first fld file. In fact that's the way to go because VisIt will cache the mesh in this case lowering the amount of data you have to read. > > Stefan > > > On Apr 12, 2010, at 11:03 AM, nek5000-users at lists.mcs.anl.gov wrote: > > >> Hi, >> >> First, I would just like to say that I am impressed by you guys (Paul >> and Stefan). You are incredible efficient in helping people out with >> their problems! >> >> This is a rather easy question I guess: How would you do in Visit when >> you have a time-varying data base without the mesh in every file (i.e. >> only in the first file)? >> >> Best regards, >> >> Johan >> >> -- >> Johan Ohlsson >> Department of Mechanics, KTH >> SE-100 44, Stockholm, Sweden >> Phone: +46 8 7906876 >> E-mail: johan at mech.kth.se >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Johan Ohlsson Department of Mechanics, KTH SE-100 44, Stockholm, Sweden Phone: +46 8 7906876 E-mail: johan at mech.kth.se From nek5000-users at lists.mcs.anl.gov Mon Apr 12 10:15:36 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 17:15:36 +0200 Subject: [Nek5000-users] -mcmodel=medium problem Message-ID: <1271085336.10936.97.camel@localhost.localdomain> Hello all, When compiling tools using "gfortran", I came across an issue with 32 bit machines, it seems that "-mcmodel=medium" is not a valid option. [root at frank tools]# ./maketools all ---------------------- Make genbox... ---------------------- make[1]: Entering directory `/root/nek5_svn/trunk/tools/genbox' gfortran -mcmodel=medium -c genbox.f genbox.f:0: error: code model ?medium? not supported in the 32 bit mode make[1]: *** [genbox.o] Error 1 If I remove "-mcmodel=medium", the resulting executable crashes [root at frank tools]# pretex -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO8859-1 Segmentation fault [root at frank ~/Desktop]# gfortran --V gfortran: no input files [root at frank ~/Desktop]# gfortran --version GNU Fortran (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27) Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING [root at frank ~/Desktop]# uname -a Linux frank 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 21:18:02 EST 2007 i686 i686 i386 GNU/Linux This is also the case for for "ifort" and "icc". ifort -mcmodel=medium -c genbox.f ifort: command line warning #10148: option '-mcmodel' not supported icc -mcmodel=medium -c -DUNDERSCORE ../../nek/byte.c icc: command line error: invalid argument for option '-m' make[1]: *** [byte.o] Error 1 Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 12 10:49:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 17:49:49 +0200 Subject: [Nek5000-users] -mcmodel=medium problem In-Reply-To: <1271085336.10936.97.camel@localhost.localdomain> References: <1271085336.10936.97.camel@localhost.localdomain> Message-ID: <2DE76B5C-6F99-4407-87FC-C6DF28E6294C@lav.mavt.ethz.ch> Please update to the latest release of the tools (r482). I disabled the BIGMEM support by default. To enable BIGMEM support just set the corresponding flag in maketools to true. Stefan On Apr 12, 2010, at 5:15 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > When compiling tools using "gfortran", I came across an issue with 32 > bit machines, it seems that "-mcmodel=medium" is not a valid option. > > [root at frank tools]# ./maketools all > ---------------------- > Make genbox... > ---------------------- > make[1]: Entering directory `/root/nek5_svn/trunk/tools/genbox' > gfortran -mcmodel=medium -c genbox.f > genbox.f:0: error: code model ?medium? not supported in the 32 bit mode > make[1]: *** [genbox.o] Error 1 > > If I remove "-mcmodel=medium", the resulting executable crashes > [root at frank tools]# pretex > -Adobe-Helvetica-Medium-R-Normal--12-120-75-75-P-67-ISO8859-1 > Segmentation fault > > > [root at frank ~/Desktop]# gfortran --V > gfortran: no input files > [root at frank ~/Desktop]# gfortran --version > GNU Fortran (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27) > Copyright (C) 2007 Free Software Foundation, Inc. > > GNU Fortran comes with NO WARRANTY, to the extent permitted by law. > You may redistribute copies of GNU Fortran > under the terms of the GNU General Public License. > For more information about these matters, see the file named COPYING > > [root at frank ~/Desktop]# uname -a > Linux frank 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 21:18:02 EST 2007 i686 > i686 i386 GNU/Linux > > > > > This is also the case for for "ifort" and "icc". > ifort -mcmodel=medium -c genbox.f > ifort: command line warning #10148: option '-mcmodel' not supported > > icc -mcmodel=medium -c -DUNDERSCORE ../../nek/byte.c > icc: command line error: invalid argument for option '-m' > make[1]: *** [byte.o] Error 1 > > Cheers, > Frank > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 12 12:41:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 12:41:15 -0500 Subject: [Nek5000-users] Calculating wall shear stress and dimensionless wall distances Message-ID: Hello, Background : I am trying to perform a LES in a turbine blade where the stream-wise, pitch-wise and span-wise direction is along X,Y and Z axis. Question : I would like to calculate the yplus and zplus values for the nodes close to the blade. For calculating the dimensionless wall distances, one would require the velocity gradients in the respective direction or the wall shear stress . I would like to know if there are any subroutines available in nek that would help calculate the wall normal distances or the velocity gradients ? Any help is greatly appreciated. Thanks Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 12 13:34:22 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 13:34:22 -0500 (CDT) Subject: [Nek5000-users] Calculating wall shear stress and dimensionless wall distances In-Reply-To: References: Message-ID: One option is to simply compute du_i/dx_j and then contract this with the unit normal on the walls in question. You could then also dump out the x,y,z, tau_w at all the points on the walls of interest... The one unfortunate thing here is that we don't have a great mechanism for interrogating/visualizing surface structure data. (I usually resort to matlab or gnuplot at that point...) Note also that you can define a quantity, let's call it u_tan, for all elements that have a "W " (wall) boundary condition. This would be a volumetric quantity for only those elements having W bc and would be defined as: U - (U.nhat)/||U|| U (which I _think_ is right, but should be checked...). Differentiating this quantity should give the shear stress at the wall. Another trick that works in limited cases (i.e., fixed surface) is vort.n_hat. After searching around a bit, probably the best example of how to compute tau_w comes from navier5.f in the /nek directory, subruoutine drgtrq(). Here is an annotated code snippet: c if (if3d.or.ifaxis) then i = 0 a = 0 do j2=js2,jf2,jskip2 ! SCAN POINTS ON FACE f of ELEMENT e do j1=js1,jf1,jskip1 i = i+1 n1 = unx(i,1,f,e)*area(i,1,f,e) ! unit normal x surface Jacobian n2 = uny(i,1,f,e)*area(i,1,f,e) n3 = unz(i,1,f,e)*area(i,1,f,e) a = a + area(i,1,f,e) c v = visc(j1,j2,1,e) c s11 = sij(j1,j2,1,1,e) ! Sij at point of interest s21 = sij(j1,j2,1,4,e) s31 = sij(j1,j2,1,6,e) c s12 = sij(j1,j2,1,4,e) s22 = sij(j1,j2,1,2,e) s32 = sij(j1,j2,1,5,e) c s13 = sij(j1,j2,1,6,e) s23 = sij(j1,j2,1,5,e) s33 = sij(j1,j2,1,3,e) c dg(1,1) = pm1(j1,j2,1,e)*n1 ! pressure drag dg(2,1) = pm1(j1,j2,1,e)*n2 dg(3,1) = pm1(j1,j2,1,e)*n3 c dg(1,2) = -v*(s11*n1 + s12*n2 + s13*n3) ! viscous drag dg(2,2) = -v*(s21*n1 + s22*n2 + s23*n3) dg(3,2) = -v*(s31*n1 + s32*n2 + s33*n3) ! Sij contracted with n_j c r1 = xm0(j1,j2,1,e) ! Position relative r2 = ym0(j1,j2,1,e) ! to where torque is desired r3 = zm0(j1,j2,1,e) c do l=1,2 do k=1,3 dgtq(k,l) = dgtq(k,l) + dg(k,l) ! Drag enddo enddo c dgtq(1,3) = dgtq(1,3) + (r2*dg(3,1)-r3*dg(2,1)) ! pressure dgtq(2,3) = dgtq(2,3) + (r3*dg(1,1)-r1*dg(3,1)) ! torque dgtq(3,3) = dgtq(3,3) + (r1*dg(2,1)-r2*dg(1,1)) c dgtq(1,4) = dgtq(1,4) + (r2*dg(3,2)-r3*dg(2,2)) ! viscous dgtq(2,4) = dgtq(2,4) + (r3*dg(1,2)-r1*dg(3,2)) ! torque dgtq(3,4) = dgtq(3,4) + (r1*dg(2,2)-r2*dg(1,2)) enddo enddo -- Paul On Mon, 12 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > Background : I am trying to perform a LES in a turbine blade where the > stream-wise, pitch-wise and span-wise direction is along X,Y and Z axis. > > Question : I would like to calculate the yplus and zplus values for the > nodes close to the blade. For calculating the dimensionless wall distances, > one would require the velocity gradients in the respective direction or the > wall shear stress . I would like to know if there are any subroutines > available in nek that would help calculate the wall normal distances or the > velocity gradients ? > > Any help is greatly appreciated. Thanks > > Regards > Shriram Jagannathan > From nek5000-users at lists.mcs.anl.gov Mon Apr 12 13:53:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 13:53:05 -0500 (CDT) Subject: [Nek5000-users] Calculating wall shear stress and dimensionless wall distances In-Reply-To: References: Message-ID: Shriram, Another option for small to medium sized data sets ( < 80,000 elements, say), is to use the profile option in postx, which will interrogate the solution along a line with up to 2000 points and then report: x,y,z,u,v,w,p,t,distance along a line (you choose which quantities you want) Given this data, you can then derive the wall-tangent velocity profile and get the wall shear. Each line is specified by x0,y0,z0 x1,y1,z1 You can list many such X0,X1 pairs in a file, and then you can use the MAKE MOVIE option in postx to run through a sequence of timesteps. All profiles are then written to profile.out, which I typically process with matlab. Paul On Mon, 12 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > Background : I am trying to perform a LES in a turbine blade where the > stream-wise, pitch-wise and span-wise direction is along X,Y and Z axis. > > Question : I would like to calculate the yplus and zplus values for the > nodes close to the blade. For calculating the dimensionless wall distances, > one would require the velocity gradients in the respective direction or the > wall shear stress . I would like to know if there are any subroutines > available in nek that would help calculate the wall normal distances or the > velocity gradients ? > > Any help is greatly appreciated. Thanks > > Regards > Shriram Jagannathan > From nek5000-users at lists.mcs.anl.gov Mon Apr 12 13:57:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 12 Apr 2010 13:57:12 -0500 (CDT) Subject: [Nek5000-users] Calculating wall shear stress and dimensionless wall distances In-Reply-To: References: Message-ID: PS -- the way to do this in postx (which assumes you have a .fld file structure and not the .f000 file structure) is: SET PLOT FORMAT X-Y PLOT SET OF PROFILES PLOT then answer the questions. You will be prompted for the name of a file containing the endpoints of each query line -- I usually call it "prof.in" You can change the line interrogation resolution (i.e., how many sample points per line) by: SET ATTRIBUTE SET RESOLUTION PROFILE POINTS 1 to 2000 is acceptable. Note that you get "n+1", so that your spacing is L/n. On Mon, 12 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > Shriram, > > Another option for small to medium sized data sets ( < 80,000 elements, > say), is to use the profile option in postx, which will interrogate the > solution along a line with up to 2000 points and then report: > > x,y,z,u,v,w,p,t,distance along a line (you choose which quantities you want) > > Given this data, you can then derive the wall-tangent velocity profile > and get the wall shear. > > Each line is specified by > > x0,y0,z0 > x1,y1,z1 > > You can list many such X0,X1 pairs in a file, and then you can > use the MAKE MOVIE option in postx to run through a sequence of > timesteps. All profiles are then written to profile.out, which > I typically process with matlab. > > Paul > > > On Mon, 12 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello, >> >> Background : I am trying to perform a LES in a turbine blade where the >> stream-wise, pitch-wise and span-wise direction is along X,Y and Z axis. >> >> Question : I would like to calculate the yplus and zplus values for the >> nodes close to the blade. For calculating the dimensionless wall distances, >> one would require the velocity gradients in the respective direction or the >> wall shear stress . I would like to know if there are any subroutines >> available in nek that would help calculate the wall normal distances or the >> velocity gradients ? >> >> Any help is greatly appreciated. Thanks >> >> Regards >> Shriram Jagannathan >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue Apr 13 04:53:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Apr 2010 09:53:44 -0000 Subject: [Nek5000-users] PN-2 & PN In-Reply-To: References: <1271062223.8715.313.camel@localhost.localdomain> <53C3F9AA-2F9F-46CA-B431-563F4E444BAC@lav.mavt.ethz.ch> <1183932183.8715.320.camel@localhost.localdomain> Message-ID: <1183932196.24221.11.camel@localhost.localdomain> Hello all, Could anyone tell me how to switch between the PN/PN and PN/PN-2 approximations? I can't seem to find this info on the wiki. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Tue Apr 13 04:46:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Apr 2010 11:46:34 +0200 Subject: [Nek5000-users] PN-2 & PN Message-ID: <1271151995.24221.13.camel@localhost.localdomain> Hello all, Could anyone tell me how to switch between the PN/PN and PN/PN-2 approximations? I can't seem to find this info on the wiki. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Tue Apr 13 05:01:18 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Apr 2010 12:01:18 +0200 Subject: [Nek5000-users] PN-2 & PN In-Reply-To: <1271151995.24221.13.camel@localhost.localdomain> References: <1271151995.24221.13.camel@localhost.localdomain> Message-ID: <50344177-CAB2-4228-8D30-768F47C67FB8@lav.mavt.ethz.ch> This depends on pressure space {lx2,ly2,lz2} in the SIZE file. PN/PN: lx2 = lx1 ly2 = lx1 lz2 = lx1 (or 1 if ldim=2) PN/PN-2 lx2 = lx1-2 ly2 = lx1-2 lz2 = lx1-2 (or 1 if ldim=2) hth, Stefan On Apr 13, 2010, at 11:46 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > Could anyone tell me how to switch between the PN/PN and PN/PN-2 > approximations? I can't seem to find this info on the wiki. > > Cheers, > Frank > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Apr 13 07:33:45 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Apr 2010 14:33:45 +0200 Subject: [Nek5000-users] Makenek compilation problems Message-ID: <4BC464A9.6030804@gmail.com> Hello all, I am a french student currently doing my final year internship, and a brand new user of Nek 5k. So far, I am not yet accustomed parallel calculations, and that is where my problems might probably come from within the following weeks. I use two computers at the lab. On my own computer, when I run ./makenek blah with the following options:/* */ /*IFMPI=true*/ /*F77="mpif77"*/ /*CC="mpicc"*/ I have absolutely no problem, the code is compiled. But when I run ./makenek blah with these options on the other one (plus */G="-g"/*), it doesn't work. I get the followinng warning message: */WARNING: Cannot detect compiler specific flags/* */ echo - to promote REAL to 8 bytes/* */ echo - to invoke preprocessor first/* */Please edit the makefile and specify the requested compiler flags in the P variable!/* I do not really know which flags I should use... Attached is the corresponding compiler.out file if needed. It would be greatly appreciated if anyone could give me a hint on what to do. Regards, Jean-Christophe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: compiler.out URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 13 07:49:47 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Apr 2010 14:49:47 +0200 Subject: [Nek5000-users] Makenek compilation problems In-Reply-To: <4BC464A9.6030804@gmail.com> References: <4BC464A9.6030804@gmail.com> Message-ID: <4D95C076-6B89-4880-B462-A5BAF44F2103@lav.mavt.ethz.ch> Hi Jean-Christophe, first of all welcome to NEK world :) I think your Fortran MPI-wrapper (mpif77) is using g77 which we do not support! Any chance to switch to another supported compiler (see here: https://nek5000.mcs.anl.gov/index.php/UG). Stefan On Apr 13, 2010, at 2:33 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I am a french student currently doing my final year internship, and a brand new user of Nek 5k. > So far, I am not yet accustomed parallel calculations, and that is where my problems might probably come from within the following weeks. > > I use two computers at the lab. On my own computer, when I run ./makenek blah with the following options:/* > */ > > /*IFMPI=true*/ > /*F77="mpif77"*/ > /*CC="mpicc"*/ > > I have absolutely no problem, the code is compiled. But when I run ./makenek blah with these options on the other one (plus */G="-g"/*), it doesn't work. I get the followinng warning message: > > */WARNING: Cannot detect compiler specific flags/* > */ echo - to promote REAL to 8 bytes/* > */ echo - to invoke preprocessor first/* > */Please edit the makefile and specify the requested compiler flags > in the P variable!/* > > I do not really know which flags I should use... Attached is the corresponding compiler.out file if needed. > > It would be greatly appreciated if anyone could give me a hint on what to do. > > Regards, > Jean-Christophe > > > mpif77 -c -g -O0 -DMPI -DLONGINT8 -I/home/loiseau/nek5_svn/trunk/nek -I/home/loiseau/nek5_svn/examples/pipe /home/loiseau/nek5_svn/trunk/nek/drive.f > mpif77 -c -g -O0 -DMPI -DLONGINT8 -I/home/loiseau/nek5_svn/trunk/nek -I/home/loiseau/nek5_svn/examples/pipe /home/loiseau/nek5_svn/trunk/nek/drive1.f > mpif77 -c -g -O0 -DMPI -DLONGINT8 -I/home/loiseau/nek5_svn/trunk/nek -I/home/loiseau/nek5_svn/examples/pipe /home/loiseau/nek5_svn/trunk/nek/drive2.f > mpif77 -c -g -O0 -DMPI -DLONGINT8 -I/home/loiseau/nek5_svn/trunk/nek -I/home/loiseau/nek5_svn/examples/pipe /home/loiseau/nek5_svn/trunk/nek/plan4.f > mpif77 -c -g -O0 -DMPI -DLONGINT8 -I/home/loiseau/nek5_svn/trunk/nek -I/home/loiseau/nek5_svn/examples/pipe /home/loiseau/nek5_svn/trunk/nek/bdry.f > SOLN: In subroutine `plan4': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN: In subroutine `nek_init': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > In file included from SOLN:350228800, > from /home/loiseau/nek5_svn/trunk/nek/plan4.f:16: > In file included from /home/loiseau/nek5_svn/trunk/nek/plan4.f:20: > /home/loiseau/nek5_svn/trunk/nek/plan4.f:57: erreur: undefined or invalid # directive > SOLN: In subroutine `initdat': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/plan4.f:62: erreur: undefined or invalid # directive > /home/loiseau/nek5_svn/trunk/nek/plan4.f:75: erreur: undefined or invalid # directive > /home/loiseau/nek5_svn/trunk/nek/plan4.f:77: erreur: undefined or invalid # directive > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `crespsp': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/drive1.f: In subroutine `nek_solve': > In file included from SOLN:155702064, > from TOTAL:11, > from /home/loiseau/nek5_svn/trunk/nek/drive1.f:6: > In file included from /home/loiseau/nek5_svn/trunk/nek/drive1.f:178: > /home/loiseau/nek5_svn/trunk/nek/drive1.f:197: erreur: undefined or invalid # directive > /home/loiseau/nek5_svn/trunk/nek/drive1.f:199: erreur: undefined or invalid # directive > /home/loiseau/nek5_svn/trunk/nek/drive1.f:200: erreur: undefined or invalid # directive > /home/loiseau/nek5_svn/trunk/nek/drive1.f:203: erreur: undefined or invalid # directive > SOLN: In subroutine `nek_advance': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/plan4.f:20: warning: > COMMON /SCRNS/ RES1 (LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/plan4.f:197: (continued): > COMMON /SCRNS/ TA1 (LX1*LY1*LZ1,LELV) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 2125440 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/plan4.f:20: warning: > COMMON /SCRNS/ RES1 (LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/plan4.f:197: (continued): > COMMON /SCRNS/ TA1 (LX1*LY1*LZ1,LELV) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 2125440 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/plan4.f:20: warning: > COMMON /SCRNS/ RES1 (LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/plan4.f:197: (continued): > COMMON /SCRNS/ TA1 (LX1*LY1*LZ1,LELV) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 2125440 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/plan4.f:20: warning: > COMMON /SCRNS/ RES1 (LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/plan4.f:197: (continued): > COMMON /SCRNS/ TA1 (LX1*LY1*LZ1,LELV) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 2125440 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/plan4.f:20: warning: > COMMON /SCRNS/ RES1 (LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/plan4.f:197: (continued): > COMMON /SCRNS/ TA1 (LX1*LY1*LZ1,LELV) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 2125440 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/plan4.f:20: warning: > COMMON /SCRNS/ RES1 (LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/plan4.f:197: (continued): > COMMON /SCRNS/ TA1 (LX1*LY1*LZ1,LELV) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 2125440 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/plan4.f:20: warning: > COMMON /SCRNS/ RES1 (LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/plan4.f:197: (continued): > COMMON /SCRNS/ TA1 (LX1*LY1*LZ1,LELV) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 2125440 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/plan4.f:20: warning: > COMMON /SCRNS/ RES1 (LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/plan4.f:197: (continued): > COMMON /SCRNS/ TA1 (LX1*LY1*LZ1,LELV) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 2125440 bytes at (2) > SOLN: In subroutine `cresvsp': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/drive1.f: In subroutine `nek_end': > In file included from SOLN:156164560, > from TOTAL:11, > from /home/loiseau/nek5_svn/trunk/nek/drive1.f:219: > In file included from /home/loiseau/nek5_svn/trunk/nek/drive1.f:283: > /home/loiseau/nek5_svn/trunk/nek/drive1.f:293: erreur: undefined or invalid # directive > /home/loiseau/nek5_svn/trunk/nek/drive1.f:298: erreur: undefined or invalid # directive > SOLN: In subroutine `bcmask': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > make: *** [drive1.o] Erreur 1 > make: *** Attente des t?ches non termin?es.... > SOLN: In subroutine `fluid': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `bcdirvc': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `op_curl': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `bcdirsc': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `rstartc': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `split_vis': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN: In subroutine `bcneusc': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `redo_split_vis': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `time00': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `nekasgn': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `bcneutr': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN: In subroutine `v_extrap': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/drive2.f: Outside of any program unit: > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > In file included from SOLN:462261632, > from TOTAL:11, > from /home/loiseau/nek5_svn/trunk/nek/drive2.f:42: > In file included from SOLN:461742752, > from /home/loiseau/nek5_svn/trunk/nek/drive2.f:731: > In file included from SOLN:463895248, > from TOTAL:11, > from /home/loiseau/nek5_svn/trunk/nek/drive2.f:900: > In file included from SOLN:465002448, > from TOTAL:11, > from /home/loiseau/nek5_svn/trunk/nek/drive2.f:1096: > In file included from /home/loiseau/nek5_svn/trunk/nek/drive2.f:1098: > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1164: erreur: undefined or invalid # directive > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `timeout': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/plan4.f:783: warning: > call add3s2(vext(1,2),vy,vylag,ab0,ab1,ntot) > ^ > Array element value at (^) out of defined range > /home/loiseau/nek5_svn/trunk/nek/plan4.f:784: warning: > if(if3d) call add3s2(vext(1,3),vz,vzlag,ab0,ab1,ntot) > ^ > Array element value at (^) out of defined range > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/plan4.f:788: warning: > call add2s2(vext(1,2),vylag(1,1,1,1,2),ab2,ntot) > ^ > Array element value at (^) out of defined range > /home/loiseau/nek5_svn/trunk/nek/plan4.f:789: warning: > if(if3d) call add2s2(vext(1,3),vzlag(1,1,1,1,2),ab2,ntot) > ^ > Array element value at (^) out of defined range > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/bdry.f:712: warning: > COMMON /SCRSF/ TMP(LX1,LY1,LZ1,LELT) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1207: (continued): > COMMON /SCRSF/ TRX(LX1,LY1,LZ1) > 2 > Common block `scrsf' is 1062720 bytes in length at (1) but 2592 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:712: warning: > COMMON /SCRSF/ TMP(LX1,LY1,LZ1,LELT) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1207: (continued): > COMMON /SCRSF/ TRX(LX1,LY1,LZ1) > 2 > Common block `scrsf' is 1062720 bytes in length at (1) but 2592 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:712: warning: > COMMON /SCRSF/ TMP(LX1,LY1,LZ1,LELT) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1207: (continued): > COMMON /SCRSF/ TRX(LX1,LY1,LZ1) > 2 > Common block `scrsf' is 1062720 bytes in length at (1) but 2592 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:712: warning: > COMMON /SCRSF/ TMP(LX1,LY1,LZ1,LELT) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1207: (continued): > COMMON /SCRSF/ TRX(LX1,LY1,LZ1) > 2 > Common block `scrsf' is 1062720 bytes in length at (1) but 2592 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:712: warning: > COMMON /SCRSF/ TMP(LX1,LY1,LZ1,LELT) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1207: (continued): > COMMON /SCRSF/ TRX(LX1,LY1,LZ1) > 2 > Common block `scrsf' is 1062720 bytes in length at (1) but 2592 bytes at (2) > make: *** [plan4.o] Erreur 1 > In file included from SOLN:464987808, > from TOTAL:11, > from /home/loiseau/nek5_svn/trunk/nek/drive2.f:1168: > In file included from /home/loiseau/nek5_svn/trunk/nek/drive2.f:1170: > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1302: erreur: undefined or invalid # directive > /home/loiseau/nek5_svn/trunk/nek/bdry.f: In subroutine `trstax': > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1353: warning: > COMMON /CTMP1/ A1X(LX1),A1Y(LX1),STX(LX1),STY(LX1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1418: (continued): > COMMON /CTMP1/ A1X(LX1),A1Y(LX1),A2X(LX1),A2Y(LX1) > 2 > Common block `ctmp1' is 96 bytes in length at (1) but 168 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1420: (continued): > COMMON /CTMP0/ XFM1(LX1),YFM1(LX1),T1XF(LX1),T1YF(LX1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 96 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1420: (continued): > COMMON /CTMP0/ XFM1(LX1),YFM1(LX1),T1XF(LX1),T1YF(LX1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 96 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1420: (continued): > COMMON /CTMP0/ XFM1(LX1),YFM1(LX1),T1XF(LX1),T1YF(LX1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 96 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1420: (continued): > COMMON /CTMP0/ XFM1(LX1),YFM1(LX1),T1XF(LX1),T1YF(LX1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 96 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1420: (continued): > COMMON /CTMP0/ XFM1(LX1),YFM1(LX1),T1XF(LX1),T1YF(LX1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 96 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1420: (continued): > COMMON /CTMP0/ XFM1(LX1),YFM1(LX1),T1XF(LX1),T1YF(LX1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 96 bytes at (2) > SOLN: In subroutine `ctang2d': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/drive2.f: In subroutine `opcount': > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1542: warning: > call csend(mtag,s,1,i,0) ! send handshake > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1591: (continued): > call csend(i,idum,4,i,0) > 2 > Argument #2 of `csend' is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1545: warning: > call crecv(i,w,m) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1592: (continued): > call crecv(i,ddcount,wdsize) > 2 > Argument #2 of `crecv' is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS] > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1545: warning: > call crecv(i,w,m) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1596: (continued): > call crecv (nid,idum,4) > 2 > Argument #2 of `crecv' is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS] > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1542: warning: > call csend(mtag,s,1,i,0) ! send handshake > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1597: (continued): > call csend (nid,dcount,wdsize,0,0) > 2 > Argument #2 of `csend' is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS] > SOLN: In subroutine `dofcnt': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/bdry.f: In subroutine `trst3d': > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1598: (continued): > COMMON /CTMP0/ XFM1(LX1,LY1),YFM1(LX1,LY1),ZFM1(LX1,LY1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 432 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1598: (continued): > COMMON /CTMP0/ XFM1(LX1,LY1),YFM1(LX1,LY1),ZFM1(LX1,LY1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 432 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1598: (continued): > COMMON /CTMP0/ XFM1(LX1,LY1),YFM1(LX1,LY1),ZFM1(LX1,LY1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 432 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1353: warning: > COMMON /CTMP1/ A1X(LX1),A1Y(LX1),STX(LX1),STY(LX1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1599: (continued): > COMMON /CTMP1/ DRM1(LX1,LX1),DRTM1(LX1,LY1) > 2 > Common block `ctmp1' is 168 bytes in length at (1) but 720 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1602: (continued): > COMMON /SCRMG/ XRM1(LX1,LY1),YRM1(LX1,LY1),ZRM1(LX1,LY1) > 2 > Common block `scrmg' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1602: (continued): > COMMON /SCRMG/ XRM1(LX1,LY1),YRM1(LX1,LY1),ZRM1(LX1,LY1) > 2 > Common block `scrmg' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1602: (continued): > COMMON /SCRMG/ XRM1(LX1,LY1),YRM1(LX1,LY1),ZRM1(LX1,LY1) > 2 > Common block `scrmg' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1602: (continued): > COMMON /SCRMG/ XRM1(LX1,LY1),YRM1(LX1,LY1),ZRM1(LX1,LY1) > 2 > Common block `scrmg' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1602: (continued): > COMMON /SCRMG/ XRM1(LX1,LY1),YRM1(LX1,LY1),ZRM1(LX1,LY1) > 2 > Common block `scrmg' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1602: (continued): > COMMON /SCRMG/ XRM1(LX1,LY1),YRM1(LX1,LY1),ZRM1(LX1,LY1) > 2 > Common block `scrmg' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:573: warning: > COMMON /SCRUZ/ TMP1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1604: (continued): > COMMON /SCRUZ/ S1X(LX1,LY1),S1Y(LX1,LY1),S1Z(LX1,LY1) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:573: warning: > COMMON /SCRUZ/ TMP1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1604: (continued): > COMMON /SCRUZ/ S1X(LX1,LY1),S1Y(LX1,LY1),S1Z(LX1,LY1) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:573: warning: > COMMON /SCRUZ/ TMP1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1604: (continued): > COMMON /SCRUZ/ S1X(LX1,LY1),S1Y(LX1,LY1),S1Z(LX1,LY1) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:573: warning: > COMMON /SCRUZ/ TMP1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1604: (continued): > COMMON /SCRUZ/ S1X(LX1,LY1),S1Y(LX1,LY1),S1Z(LX1,LY1) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:573: warning: > COMMON /SCRUZ/ TMP1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1604: (continued): > COMMON /SCRUZ/ S1X(LX1,LY1),S1Y(LX1,LY1),S1Z(LX1,LY1) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:573: warning: > COMMON /SCRUZ/ TMP1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1604: (continued): > COMMON /SCRUZ/ S1X(LX1,LY1),S1Y(LX1,LY1),S1Z(LX1,LY1) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1598: (continued): > COMMON /CTMP0/ XFM1(LX1,LY1),YFM1(LX1,LY1),ZFM1(LX1,LY1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 432 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1602: (continued): > COMMON /SCRMG/ XRM1(LX1,LY1),YRM1(LX1,LY1),ZRM1(LX1,LY1) > 2 > Common block `scrmg' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:573: warning: > COMMON /SCRUZ/ TMP1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1604: (continued): > COMMON /SCRUZ/ S1X(LX1,LY1),S1Y(LX1,LY1),S1Z(LX1,LY1) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:573: warning: > COMMON /SCRUZ/ TMP1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1604: (continued): > COMMON /SCRUZ/ S1X(LX1,LY1),S1Y(LX1,LY1),S1Z(LX1,LY1) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1602: (continued): > COMMON /SCRMG/ XRM1(LX1,LY1),YRM1(LX1,LY1),ZRM1(LX1,LY1) > 2 > Common block `scrmg' is 1062720 bytes in length at (1) but 864 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1210: warning: > COMMON /CTMP0/ STC(LX1,LY1,LZ1) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1598: (continued): > COMMON /CTMP0/ XFM1(LX1,LY1),YFM1(LX1,LY1),ZFM1(LX1,LY1) > 2 > Common block `ctmp0' is 864 bytes in length at (1) but 432 bytes at (2) > SOLN: In subroutine `setshl': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1850: (continued): > COMMON /SCRMG/ V1(LX1,LY1,LZ1,LELV) > 2 > Common block `scrmg' is 1062720 bytes in length at (1) but 1416960 bytes at (2) > SOLN: In subroutine `vol_flow': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `chkzvn': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `check_cyclic': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > SOLN: In subroutine `compute_vol_soln': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1992: (continued): > common /scrmg/ v1(lx1,ly1,lz1,lelt) > 2 > Common block `scrmg' is 1416960 bytes in length at (1) but 1062720 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1992: (continued): > common /scrmg/ v1(lx1,ly1,lz1,lelt) > 2 > Common block `scrmg' is 1416960 bytes in length at (1) but 1062720 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1992: (continued): > common /scrmg/ v1(lx1,ly1,lz1,lelt) > 2 > Common block `scrmg' is 1416960 bytes in length at (1) but 1062720 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1992: (continued): > common /scrmg/ v1(lx1,ly1,lz1,lelt) > 2 > Common block `scrmg' is 1416960 bytes in length at (1) but 1062720 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/bdry.f:576: warning: > COMMON /SCRMG/ TMQ1(LX1,LY1,LZ1,LELV) > 1 > /home/loiseau/nek5_svn/trunk/nek/bdry.f:1992: (continued): > common /scrmg/ v1(lx1,ly1,lz1,lelt) > 2 > Common block `scrmg' is 1416960 bytes in length at (1) but 1062720 bytes at (2) > make: *** [bdry.o] Erreur 1 > SOLN: In subroutine `plan2_vol': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2042: (continued): > COMMON /SCRNS/ RESV1 (LX1,LY1,LZ1,LELV) > 2 > Common block `scrns' is 1416960 bytes in length at (1) but 1167680 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2042: (continued): > COMMON /SCRNS/ RESV1 (LX1,LY1,LZ1,LELV) > 2 > Common block `scrns' is 1416960 bytes in length at (1) but 1167680 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2042: (continued): > COMMON /SCRNS/ RESV1 (LX1,LY1,LZ1,LELV) > 2 > Common block `scrns' is 1416960 bytes in length at (1) but 1167680 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2042: (continued): > COMMON /SCRNS/ RESV1 (LX1,LY1,LZ1,LELV) > 2 > Common block `scrns' is 1416960 bytes in length at (1) but 1167680 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2042: (continued): > COMMON /SCRNS/ RESV1 (LX1,LY1,LZ1,LELV) > 2 > Common block `scrns' is 1416960 bytes in length at (1) but 1167680 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2042: (continued): > COMMON /SCRNS/ RESV1 (LX1,LY1,LZ1,LELV) > 2 > Common block `scrns' is 1416960 bytes in length at (1) but 1167680 bytes at (2) > SOLN: In subroutine `plan3_vol': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2155: (continued): > COMMON /SCRNS/ rw1 (LX1,LY1,LZ1,LELV) > 2 > Common block `scrns' is 1416960 bytes in length at (1) but 2230400 bytes at (2) > SOLN: In subroutine `a_dmp': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2225: (continued): > COMMON /SCRNS/ w(LX1,LY1,LZ1,LELT) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 354240 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2225: (continued): > COMMON /SCRNS/ w(LX1,LY1,LZ1,LELT) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 354240 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/drive2.f:1681: warning: > COMMON /SCRNS/ WORK(LCTMP1) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2225: (continued): > COMMON /SCRNS/ w(LX1,LY1,LZ1,LELT) > 2 > Common block `scrns' is 2230400 bytes in length at (1) but 354240 bytes at (2) > SOLN: In subroutine `reset_prop': > SOLN:14: > parameter (lorder2 = max(1,lorder-2) ) > ^ > Invalid declaration of or reference to symbol `max' at (^) [initially seen at (^)] > SOLN:63: > $ , PMLAG (LBX2*LBY2*LBZ2*LBELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `pmlag' at (^) [initially seen at (^)] > SOLN:67: > $ , PRLAG (LX2,LY2,LZ2,LELV,LORDER2) > ^ > Invalid declaration of or reference to symbol `prlag' at (^) [initially seen at (^)] > SOLN:99: > $ , PRLAGP (LPX2*LPY2*LPZ2*LPELV,LORDER2,lpert) > ^ > Invalid declaration of or reference to symbol `prlagp' at (^) [initially seen at (^)] > /home/loiseau/nek5_svn/trunk/nek/drive2.f:470: warning: > COMMON /SCRUZ/ XM3 (LX3,LY3,LZ3,LELT) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2380: (continued): > COMMON /SCRUZ/ TA(LX1,LY1,LZ1,LELT) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 354240 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/drive2.f:470: warning: > COMMON /SCRUZ/ XM3 (LX3,LY3,LZ3,LELT) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2380: (continued): > COMMON /SCRUZ/ TA(LX1,LY1,LZ1,LELT) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 354240 bytes at (2) > /home/loiseau/nek5_svn/trunk/nek/drive2.f:470: warning: > COMMON /SCRUZ/ XM3 (LX3,LY3,LZ3,LELT) > 1 > /home/loiseau/nek5_svn/trunk/nek/drive2.f:2380: (continued): > COMMON /SCRUZ/ TA(LX1,LY1,LZ1,LELT) > 2 > Common block `scruz' is 1062720 bytes in length at (1) but 354240 bytes at (2) > make: *** [drive2.o] Erreur 1 > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Apr 13 09:44:51 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 13 Apr 2010 16:44:51 +0200 Subject: [Nek5000-users] Makenek compilation problems In-Reply-To: <4D95C076-6B89-4880-B462-A5BAF44F2103@lav.mavt.ethz.ch> References: <4BC464A9.6030804@gmail.com> <4D95C076-6B89-4880-B462-A5BAF44F2103@lav.mavt.ethz.ch> Message-ID: <4BC48363.8030904@gmail.com> I switch it to ifort, and it works perfectly now. Thanks a lot. Jean-Christophe From nek5000-users at lists.mcs.anl.gov Wed Apr 14 02:57:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 09:57:23 +0200 Subject: [Nek5000-users] axisymmetric and 2D Message-ID: <1271231843.24221.62.camel@localhost.localdomain> Hello all, Could anyone tell me how to switch between axisymmetric and 2D (Cartesian) mode? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 14 03:05:18 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 03:05:18 -0500 (CDT) Subject: [Nek5000-users] axisymmetric and 2D In-Reply-To: <1271231843.24221.62.camel@localhost.localdomain> References: <1271231843.24221.62.camel@localhost.localdomain> Message-ID: Set IFAXIS to F in the .rea file Make certain that any "A " bcs (indicating an element edge at r (y)=0 are set to SYM for velocity and "I " for temperature. Paul On Wed, 14 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, Could anyone tell me how to switch between axisymmetric and 2D (Cartesian) mode? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 14 03:05:33 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 10:05:33 +0200 Subject: [Nek5000-users] axisymmetric and 2D In-Reply-To: <1271231843.24221.62.camel@localhost.localdomain> References: <1271231843.24221.62.camel@localhost.localdomain> Message-ID: <202BCE3B-12D3-467B-856B-8A059B9B36A0@lav.mavt.ethz.ch> Use the IFAXIS switch (see logical switches in the .rea file). Stefan On Apr 14, 2010, at 9:57 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > Could anyone tell me how to switch between axisymmetric and 2D > (Cartesian) mode? > > Cheers, > Frank > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 14 03:11:45 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 10:11:45 +0200 Subject: [Nek5000-users] axisymmetric and 2D In-Reply-To: <202BCE3B-12D3-467B-856B-8A059B9B36A0@lav.mavt.ethz.ch> References: <1271231843.24221.62.camel@localhost.localdomain> <202BCE3B-12D3-467B-856B-8A059B9B36A0@lav.mavt.ethz.ch> Message-ID: Shoot Paul was 12 sec faster :) Stefan On Apr 14, 2010, at 10:05 AM, nek5000-users at lists.mcs.anl.gov wrote: > Use the IFAXIS switch (see logical switches in the .rea file). > > Stefan > > > On Apr 14, 2010, at 9:57 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello all, >> >> Could anyone tell me how to switch between axisymmetric and 2D >> (Cartesian) mode? >> >> Cheers, >> Frank >> >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 >> Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 14 03:25:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 10:25:48 +0200 Subject: [Nek5000-users] Example 'turbChannel' Emergency exit Message-ID: <4BC57C0C.4000800@kit.edu> Hello NEKs, in the last day I had a couple of problems with my runs, so I started again the turbChannel example on our machine to get a better feeling for the parameters. When I run the turbChannel example, the run stopped after 5172 time steps with an 'emergency exit' cause the CFL number is getting to high. Do you know from where does this occur?? I just added the output of the last time steps. Best, Fred 5165 2.582500000E+01 3.916990657E-03 1.659821813E-03 3.694680560E-01 e2 Step 5166, t= 2.5830000E+01, DT= 5.0000000E-03, C= 2.079 3.4805E+04 1.3937E+01 Solving for fluid 5166 PRES alph1n 8.7741E+02 4.2415E+01 2.0687E+01 20 5166 PRES halpha 20 1.1643E+01 -3.7137E+00 3.6211E-01 -2.0448E-01 -1.6916E+00 8.2524E-01 1.1625E+00 8.9342E-01 -1.6984E-01 -2.2222E-01 5166 PRES gmres: 75 8.8674E-06 1.0000E-05 8.5433E-02 4.1833E+00 9.7743E+00 5166 Hmholtz VELX: 11 1.5456E-09 1.0149E+00 1.0000E-08 5166 Hmholtz VELY: 11 3.0012E-09 1.9688E+00 1.0000E-08 5166 Hmholtz VELZ: 11 2.5093E-09 1.8625E+00 1.0000E-08 L1/L2 DIV(V) : 4.9352E-18 9.2917E-01 L1/L2 QTL : 0.0000E+00 0.0000E+00 L1/L2 DIV(V)-QTL: 4.9352E-18 9.2917E-01 WARNING: DIV(V)-QTL too large! 5166 2.5830E+01 1.3669E+01 Fluid done Calculating eddy visosity 5166 2.583000000E+01 3.926052513E-03 1.662276122E-03 3.689963050E-01 e2 Step 5167, t= 2.5835000E+01, DT= 5.0000000E-03, C= 2.889 3.4820E+04 1.4982E+01 Solving for fluid 5167 PRES alph1n 1.5542E+03 7.1980E+02 2.1591E+00 1 5167 PRES halpha 1 1.4480E+01 5167 PRES gmres: 86 9.7160E-06 1.0000E-05 9.3445E-01 4.7986E+00 1.1231E+01 5167 Hmholtz VELX: 12 5.8389E-09 1.3413E+00 1.0000E-08 5167 Hmholtz VELY: 13 3.9482E-09 2.9638E+00 1.0000E-08 5167 Hmholtz VELZ: 13 3.5924E-09 2.6194E+00 1.0000E-08 L1/L2 DIV(V) : 3.1068E-18 1.2785E+00 L1/L2 QTL : 0.0000E+00 0.0000E+00 L1/L2 DIV(V)-QTL: 3.1068E-18 1.2785E+00 WARNING: DIV(V)-QTL too large! 5167 2.5835E+01 1.5275E+01 Fluid done Calculating eddy visosity 5167 2.583500000E+01 3.993359862E-03 1.664692380E-03 3.685384235E-01 e2 Step 5168, t= 2.5840000E+01, DT= 5.0000000E-03, C= 3.423 3.4837E+04 1.6588E+01 Solving for fluid 5168 PRES alph1n 3.9778E+03 3.8710E+03 1.0276E+00 2 5168 PRES halpha 2 1.2944E+01 6.2999E-01 5168 PRES gmres: 79 9.2196E-06 1.0000E-05 4.3331E+00 4.4083E+00 1.0437E+01 5168 Hmholtz VELX: 14 4.7243E-09 2.0176E+00 1.0000E-08 5168 Hmholtz VELY: 14 6.8219E-09 4.6788E+00 1.0000E-08 5168 Hmholtz VELZ: 15 1.8252E-09 4.0913E+00 1.0000E-08 L1/L2 DIV(V) : -1.4831E-18 2.0942E+00 L1/L2 QTL : 0.0000E+00 0.0000E+00 L1/L2 DIV(V)-QTL: -1.4831E-18 2.0942E+00 WARNING: DIV(V)-QTL too large! 5168 2.5840E+01 1.4678E+01 Fluid done Calculating eddy visosity 5168 2.584000000E+01 4.200707570E-03 1.667064185E-03 3.681057305E-01 e2 Step 5169, t= 2.5845000E+01, DT= 5.0000000E-03, C= 5.530 3.4853E+04 1.5991E+01 Solving for fluid 5169 PRES alph1n 7.2030E+03 3.1162E+03 2.3115E+00 3 5169 PRES halpha 3 -6.0424E+01 -1.0653E+01 -8.4291E+00 5169 PRES gmres: 97 9.6453E-06 1.0000E-05 3.9350E+00 5.4119E+00 1.2493E+01 5169 Hmholtz VELX: 11 4.1711E-09 1.9124E+00 1.0000E-08 5169 Hmholtz VELY: 11 7.0818E-09 3.3758E+00 1.0000E-08 5169 Hmholtz VELZ: 11 9.3833E-09 4.3104E+00 1.0000E-08 L1/L2 DIV(V) : 5.4916E-18 2.0864E+00 L1/L2 QTL : 0.0000E+00 0.0000E+00 L1/L2 DIV(V)-QTL: 5.4916E-18 2.0864E+00 WARNING: DIV(V)-QTL too large! 5169 2.5845E+01 1.6361E+01 Fluid done Calculating eddy visosity 5169 2.584500000E+01 4.167598852E-03 1.701730652E-03 3.676193877E-01 e2 Step 5170, t= 2.5850000E+01, DT= 5.0000000E-03, C= 6.006 3.4871E+04 1.7673E+01 Solving for fluid 5170 PRES alph1n 3.8504E+03 2.1151E+03 1.8205E+00 4 5170 PRES halpha 4 -4.5903E+00 2.8727E+00 1.4775E+00 -3.0313E+01 5170 PRES gmres: 95 9.5031E-06 1.0000E-05 2.9323E+00 5.3008E+00 1.2248E+01 5170 Hmholtz VELX: 11 2.9823E-09 2.3489E+00 1.0000E-08 5170 Hmholtz VELY: 11 5.2939E-09 5.2327E+00 1.0000E-08 5170 Hmholtz VELZ: 11 8.5864E-09 6.0722E+00 1.0000E-08 L1/L2 DIV(V) : -1.3376E-19 1.6752E+00 L1/L2 QTL : 0.0000E+00 0.0000E+00 L1/L2 DIV(V)-QTL: -1.3376E-19 1.6752E+00 WARNING: DIV(V)-QTL too large! 5170 2.5850E+01 1.6120E+01 Fluid done Calculating eddy visosity 5170 2.585000000E+01 4.085734913E-03 1.716209642E-03 3.671058529E-01 e2 Step 5171, t= 2.5855000E+01, DT= 5.0000000E-03, C= 4.227 3.4888E+04 1.7434E+01 Solving for fluid 5171 PRES alph1n 5.0358E+03 1.2448E+03 4.0456E+00 5 5171 PRES halpha 5 -6.9028E+00 -1.4184E+00 -4.2028E+01 -1.2786E+01 -2.1059E+01 5171 PRES gmres: 92 9.4249E-06 1.0000E-05 1.6822E+00 5.1338E+00 1.1887E+01 5171 Hmholtz VELX: 11 2.1456E-09 2.9780E+00 1.0000E-08 5171 Hmholtz VELY: 11 5.3606E-09 7.0811E+00 1.0000E-08 5171 Hmholtz VELZ: 11 5.8359E-09 6.8710E+00 1.0000E-08 L1/L2 DIV(V) : -1.6210E-17 3.1098E+00 L1/L2 QTL : 0.0000E+00 0.0000E+00 L1/L2 DIV(V)-QTL: -1.6210E-17 3.1098E+00 WARNING: DIV(V)-QTL too large! 5171 2.5855E+01 1.5761E+01 Fluid done Calculating eddy visosity 5171 2.585500000E+01 4.389947285E-03 1.720108719E-03 3.665677180E-01 e2 Step 5172, t= 2.5860000E+01, DT= 5.0000000E-03, C= 14.041 3.4905E+04 1.7076E+01 Solving for fluid 5172 PRES alph1n 9.0973E+04 3.3755E+04 2.6951E+00 6 5172 PRES halpha 6 -5.1818E+02 -1.4428E+02 -8.2239E+02 -5.2616E+01 6.5613E+01 2.1168E+02 5172 PRES gmres: 132 9.6516E-06 1.0000E-05 4.3975E+01 7.3637E+00 1.7181E+01 5172 Hmholtz VELX: 32 8.9325E-09 4.2902E+01 1.0000E-08 5172 Hmholtz VELY: 33 6.7432E-09 1.0998E+02 1.0000E-08 5172 Hmholtz VELZ: 33 8.7122E-09 9.2142E+01 1.0000E-08 L1/L2 DIV(V) : -4.3714E-18 1.8897E+01 L1/L2 QTL : 0.0000E+00 0.0000E+00 L1/L2 DIV(V)-QTL: -4.3714E-18 1.8897E+01 WARNING: DIV(V)-QTL too large! 5172 2.5860E+01 2.3473E+01 Fluid done Calculating eddy visosity 5172 2.586000000E+01 4.640317048E-02 1.721776888E-03 3.660847580E-01 e2 CFL, Ctarg! 77.0972671240189 2.00000000000000 5173 2.5860E+01 Write checkpoint: 5173 2.5860E+01 OPEN: turbChannel.fld06 1 Emergency exit: 5173 time = 25.8599999999991 Latest solution and data are dumped for post-processing. *** STOP *** 0 Emergency exit: 5173 time = 25.8599999999991 Latest solution and data are dumped for post-processing. *** STOP *** 0 opcount 7939907566848.00 1 opcount 7939907566848.00 TOTAL OPCOUNT 15879815133696.0 opnode 0 subcl4 0.000000 0 opnode 0 ascol5 0.000000 0 opnode 0 invcl3 0.1355809E+10 10344 opnode 0 vlsum 0.1355809E+10 2648064 opnode 0 inver2 0.1355809E+10 10344 opnode 0 cadd2 0.2033713E+10 15516 opnode 0 admcol 0.2033713E+10 5172 opnode 0 invcl1 0.2033713E+10 15516 opnode 0 vsqrt 0.3389915E+10 2663583 opnode 0 opa2cl 0.4067426E+10 5172 opnode 0 subcl3 0.4067426E+10 15516 opnode 0 sub3 0.4747952E+10 37499 opnode 0 sub2 0.1152359E+11 8001078 opnode 0 opcv3c 0.1219992E+11 15513 opnode 0 add3s2 0.1220228E+11 31032 opnode 0 VLSC2 0.1285580E+11 49041 opnode 0 cadd 0.1391945E+11 106197 opnode 0 invcl2 0.1423639E+11 19891515 opnode 0 opcolv 0.2643827E+11 67236 opnode 0 add2s1 0.2927781E+11 111686 opnode 0 glsc2 0.3054948E+11 116537 opnode 0 ADD3 0.3129265E+11 61118464 opnode 0 cmult 0.4078676E+11 64159596 opnode 0 addcl4 0.4189481E+11 106544 opnode 0 col3 0.6824224E+11 32173287 opnode 0 ADD2 0.8181750E+11 85243418 opnode 0 glsc3 0.8983806E+11 228470 opnode 0 addcl3 0.1057688E+12 63724056 opnode 0 col2 0.2130625E+12 254874963 opnode 0 add2s2 0.3703272E+12 1412686 opnode 0 VLSC3 0.4606404E+12 1171469 opnode 0 mxm 0.6246592E+13 -1613811570 total time 34934.7607588768 34931.1205290364 copy time 0 0.000000000000000E+000 0.000000000000000E+000 mxmf time 0 0.000000000000000E+000 0.000000000000000E+000 inv3 time 10344 15.3735277652740 4.401097798307057E-004 invc time 19891515 146.002576589584 4.179727829464278E-003 mltd time 62064 4038.74821758270 0.115620345308577 cdtp time 15516 437.695099830627 1.253023359118396E-002 eslv time 0 0.000000000000000E+000 0.000000000000000E+000 pres time 5172 14242.1249115467 0.407720241888833 crsl time 90681 47.9217271804810 1.371892068009847E-003 crsl min 47.9217271804810 crsl max 53.2970800399780 crsl avg 50.6094036102295 hmhz time 15521 15087.4339959621 0.431919553895237 usbc time 5173 85.1574075222015 2.437866470713835E-003 axhm time 238766 6975.35609674454 0.199688873162437 advc time -1333526528 2.332305834658064E-310 6.676870938527185E-315 gop time 878153 62.8719458580017 1.799883453659598E-003 gop min 62.8719387054443 gop max 118.545093774796 gop avg 90.7085191011429 vdss time 25861 108.827995061874 3.115502549407525E-003 vdss min 108.827995061874 vdss max 108.830206155777 vdss avg 108.829100608826 dsum time 334612 471.267515897751 1.349133691563118E-002 dsum min 440.130956649780 dsum max 471.267515897751 dsum avg 455.699236273766 gsum time 0 0.000000000000000E+000 0.000000000000000E+000 dsnd time 0 0.000000000000000E+000 0.000000000000000E+000 dadd time 0 0.000000000000000E+000 0.000000000000000E+000 dsmx time 0 0.154825925827026 4.432320620757866E-006 dsmn time 0 1.043796539306641E-003 2.988156473363023E-008 slvb time 0 0.000000000000000E+000 0.000000000000000E+000 ddsl time 0 0.000000000000000E+000 0.000000000000000E+000 solv time 0 0.000000000000000E+000 0.000000000000000E+000 sett time 0 0.000000000000000E+000 0.000000000000000E+000 prep time 5173 12.7582430839539 3.652400178044276E-004 bsol time 0 0.000000000000000E+000 0.000000000000000E+000 bso2 time 0 0.000000000000000E+000 0.000000000000000E+000 # nid tusbc tdadd tcrsl tvdss tdsum tgop qqq 0 8.5157E+01 0.0000E+00 4.7922E+01 1.0883E+02 4.7127E+02 6.2872E+01 qqq 1 8.8959E+01 0.0000E+00 5.3297E+01 1.0883E+02 4.4013E+02 1.1855E+02 qqq call exitt: dying ... backtrace(): obtained 11 stack frames. /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(print_stack_+0x26) [0x5d34ca] /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(exitt_+0x34e) [0x6eb7ce] /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(emerxit_+0x63c) [0x52deaa] /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(setdt_+0xc9a) [0x52098a] /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(settime_+0xb7) [0x4210a1] /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_advance_+0x27) [0x41d185] /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_solve_+0x2d1) [0x41d0d3] /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(MAIN__+0x3b) [0x41bfaf] /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(main+0x3c) [0x415b8c] /lib/libc.so.6(__libc_start_main+0xda) [0x2aef191be4ca] /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(for_write_seq_fmt_xmit+0x3a) [0x415aba] total elapsed time : 3.49348E+04 sec total solver time incl. I/O : 3.49051E+04 sec time/timestep : 6.74756E+00 sec CPU seconds/timestep/DOF : 7.82568E-05 sec From nek5000-users at lists.mcs.anl.gov Wed Apr 14 03:37:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 10:37:21 +0200 Subject: [Nek5000-users] Example 'turbChannel' Emergency exit In-Reply-To: <4BC57C0C.4000800@kit.edu> References: <4BC57C0C.4000800@kit.edu> Message-ID: <6C58009F-4C89-4922-99B7-064BE8066A1E@lav.mavt.ethz.ch> Hi Fred, please attach a full logfile. Stefan On Apr 14, 2010, at 10:25 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello NEKs, > > in the last day I had a couple of problems with my runs, so I started again the turbChannel example on our machine to get a better feeling for the parameters. When I run the turbChannel example, the run stopped after 5172 time steps with an 'emergency exit' cause the CFL number is getting to high. Do you know from where does this occur?? I just added the output of the last time steps. > > Best, > Fred > > > 5165 2.582500000E+01 3.916990657E-03 1.659821813E-03 3.694680560E-01 e2 > Step 5166, t= 2.5830000E+01, DT= 5.0000000E-03, C= 2.079 3.4805E+04 1.3937E+01 > Solving for fluid > 5166 PRES alph1n 8.7741E+02 4.2415E+01 2.0687E+01 20 > 5166 PRES halpha 20 1.1643E+01 -3.7137E+00 3.6211E-01 -2.0448E-01 -1.6916E+00 8.2524E-01 1.1625E+00 8.9342E-01 -1.6984E-01 -2.2222E-01 > > 5166 PRES gmres: 75 8.8674E-06 1.0000E-05 8.5433E-02 4.1833E+00 9.7743E+00 > 5166 Hmholtz VELX: 11 1.5456E-09 1.0149E+00 1.0000E-08 > 5166 Hmholtz VELY: 11 3.0012E-09 1.9688E+00 1.0000E-08 > 5166 Hmholtz VELZ: 11 2.5093E-09 1.8625E+00 1.0000E-08 > L1/L2 DIV(V) : 4.9352E-18 9.2917E-01 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: 4.9352E-18 9.2917E-01 > WARNING: DIV(V)-QTL too large! > 5166 2.5830E+01 1.3669E+01 Fluid done > Calculating eddy visosity > 5166 2.583000000E+01 3.926052513E-03 1.662276122E-03 3.689963050E-01 e2 > Step 5167, t= 2.5835000E+01, DT= 5.0000000E-03, C= 2.889 3.4820E+04 1.4982E+01 > Solving for fluid > 5167 PRES alph1n 1.5542E+03 7.1980E+02 2.1591E+00 1 > 5167 PRES halpha 1 1.4480E+01 > 5167 PRES gmres: 86 9.7160E-06 1.0000E-05 9.3445E-01 4.7986E+00 1.1231E+01 > 5167 Hmholtz VELX: 12 5.8389E-09 1.3413E+00 1.0000E-08 > 5167 Hmholtz VELY: 13 3.9482E-09 2.9638E+00 1.0000E-08 > 5167 Hmholtz VELZ: 13 3.5924E-09 2.6194E+00 1.0000E-08 > L1/L2 DIV(V) : 3.1068E-18 1.2785E+00 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: 3.1068E-18 1.2785E+00 > WARNING: DIV(V)-QTL too large! > 5167 2.5835E+01 1.5275E+01 Fluid done > Calculating eddy visosity > 5167 2.583500000E+01 3.993359862E-03 1.664692380E-03 3.685384235E-01 e2 > Step 5168, t= 2.5840000E+01, DT= 5.0000000E-03, C= 3.423 3.4837E+04 1.6588E+01 > Solving for fluid > 5168 PRES alph1n 3.9778E+03 3.8710E+03 1.0276E+00 2 > 5168 PRES halpha 2 1.2944E+01 6.2999E-01 > 5168 PRES gmres: 79 9.2196E-06 1.0000E-05 4.3331E+00 4.4083E+00 1.0437E+01 > 5168 Hmholtz VELX: 14 4.7243E-09 2.0176E+00 1.0000E-08 > 5168 Hmholtz VELY: 14 6.8219E-09 4.6788E+00 1.0000E-08 > 5168 Hmholtz VELZ: 15 1.8252E-09 4.0913E+00 1.0000E-08 > L1/L2 DIV(V) : -1.4831E-18 2.0942E+00 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: -1.4831E-18 2.0942E+00 > WARNING: DIV(V)-QTL too large! > 5168 2.5840E+01 1.4678E+01 Fluid done > Calculating eddy visosity > 5168 2.584000000E+01 4.200707570E-03 1.667064185E-03 3.681057305E-01 e2 > Step 5169, t= 2.5845000E+01, DT= 5.0000000E-03, C= 5.530 3.4853E+04 1.5991E+01 > Solving for fluid > 5169 PRES alph1n 7.2030E+03 3.1162E+03 2.3115E+00 3 > 5169 PRES halpha 3 -6.0424E+01 -1.0653E+01 -8.4291E+00 > 5169 PRES gmres: 97 9.6453E-06 1.0000E-05 3.9350E+00 5.4119E+00 1.2493E+01 > 5169 Hmholtz VELX: 11 4.1711E-09 1.9124E+00 1.0000E-08 > 5169 Hmholtz VELY: 11 7.0818E-09 3.3758E+00 1.0000E-08 > 5169 Hmholtz VELZ: 11 9.3833E-09 4.3104E+00 1.0000E-08 > L1/L2 DIV(V) : 5.4916E-18 2.0864E+00 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: 5.4916E-18 2.0864E+00 > WARNING: DIV(V)-QTL too large! > 5169 2.5845E+01 1.6361E+01 Fluid done > Calculating eddy visosity > 5169 2.584500000E+01 4.167598852E-03 1.701730652E-03 3.676193877E-01 e2 > Step 5170, t= 2.5850000E+01, DT= 5.0000000E-03, C= 6.006 3.4871E+04 1.7673E+01 > Solving for fluid > 5170 PRES alph1n 3.8504E+03 2.1151E+03 1.8205E+00 4 > 5170 PRES halpha 4 -4.5903E+00 2.8727E+00 1.4775E+00 -3.0313E+01 > 5170 PRES gmres: 95 9.5031E-06 1.0000E-05 2.9323E+00 5.3008E+00 1.2248E+01 > 5170 Hmholtz VELX: 11 2.9823E-09 2.3489E+00 1.0000E-08 > 5170 Hmholtz VELY: 11 5.2939E-09 5.2327E+00 1.0000E-08 > 5170 Hmholtz VELZ: 11 8.5864E-09 6.0722E+00 1.0000E-08 > L1/L2 DIV(V) : -1.3376E-19 1.6752E+00 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: -1.3376E-19 1.6752E+00 > WARNING: DIV(V)-QTL too large! > 5170 2.5850E+01 1.6120E+01 Fluid done > Calculating eddy visosity > 5170 2.585000000E+01 4.085734913E-03 1.716209642E-03 3.671058529E-01 e2 > Step 5171, t= 2.5855000E+01, DT= 5.0000000E-03, C= 4.227 3.4888E+04 1.7434E+01 > Solving for fluid > 5171 PRES alph1n 5.0358E+03 1.2448E+03 4.0456E+00 5 > 5171 PRES halpha 5 -6.9028E+00 -1.4184E+00 -4.2028E+01 -1.2786E+01 -2.1059E+01 > 5171 PRES gmres: 92 9.4249E-06 1.0000E-05 1.6822E+00 5.1338E+00 1.1887E+01 > 5171 Hmholtz VELX: 11 2.1456E-09 2.9780E+00 1.0000E-08 > 5171 Hmholtz VELY: 11 5.3606E-09 7.0811E+00 1.0000E-08 > 5171 Hmholtz VELZ: 11 5.8359E-09 6.8710E+00 1.0000E-08 > L1/L2 DIV(V) : -1.6210E-17 3.1098E+00 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: -1.6210E-17 3.1098E+00 > WARNING: DIV(V)-QTL too large! > 5171 2.5855E+01 1.5761E+01 Fluid done > Calculating eddy visosity > 5171 2.585500000E+01 4.389947285E-03 1.720108719E-03 3.665677180E-01 e2 > Step 5172, t= 2.5860000E+01, DT= 5.0000000E-03, C= 14.041 3.4905E+04 1.7076E+01 > Solving for fluid > 5172 PRES alph1n 9.0973E+04 3.3755E+04 2.6951E+00 6 > 5172 PRES halpha 6 -5.1818E+02 -1.4428E+02 -8.2239E+02 -5.2616E+01 6.5613E+01 2.1168E+02 > 5172 PRES gmres: 132 9.6516E-06 1.0000E-05 4.3975E+01 7.3637E+00 1.7181E+01 > 5172 Hmholtz VELX: 32 8.9325E-09 4.2902E+01 1.0000E-08 > 5172 Hmholtz VELY: 33 6.7432E-09 1.0998E+02 1.0000E-08 > 5172 Hmholtz VELZ: 33 8.7122E-09 9.2142E+01 1.0000E-08 > L1/L2 DIV(V) : -4.3714E-18 1.8897E+01 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: -4.3714E-18 1.8897E+01 > WARNING: DIV(V)-QTL too large! > 5172 2.5860E+01 2.3473E+01 Fluid done > Calculating eddy visosity > 5172 2.586000000E+01 4.640317048E-02 1.721776888E-03 3.660847580E-01 e2 > CFL, Ctarg! 77.0972671240189 2.00000000000000 > > 5173 2.5860E+01 Write checkpoint: > > 5173 2.5860E+01 OPEN: turbChannel.fld06 > > 1 Emergency exit: 5173 time = 25.8599999999991 > Latest solution and data are dumped for post-processing. > *** STOP *** > > 0 Emergency exit: 5173 time = 25.8599999999991 > Latest solution and data are dumped for post-processing. > *** STOP *** > 0 opcount 7939907566848.00 > 1 opcount 7939907566848.00 > TOTAL OPCOUNT 15879815133696.0 > opnode 0 subcl4 0.000000 0 > opnode 0 ascol5 0.000000 0 > opnode 0 invcl3 0.1355809E+10 10344 > opnode 0 vlsum 0.1355809E+10 2648064 > opnode 0 inver2 0.1355809E+10 10344 > opnode 0 cadd2 0.2033713E+10 15516 > opnode 0 admcol 0.2033713E+10 5172 > opnode 0 invcl1 0.2033713E+10 15516 > opnode 0 vsqrt 0.3389915E+10 2663583 > opnode 0 opa2cl 0.4067426E+10 5172 > opnode 0 subcl3 0.4067426E+10 15516 > opnode 0 sub3 0.4747952E+10 37499 > opnode 0 sub2 0.1152359E+11 8001078 > opnode 0 opcv3c 0.1219992E+11 15513 > opnode 0 add3s2 0.1220228E+11 31032 > opnode 0 VLSC2 0.1285580E+11 49041 > opnode 0 cadd 0.1391945E+11 106197 > opnode 0 invcl2 0.1423639E+11 19891515 > opnode 0 opcolv 0.2643827E+11 67236 > opnode 0 add2s1 0.2927781E+11 111686 > opnode 0 glsc2 0.3054948E+11 116537 > opnode 0 ADD3 0.3129265E+11 61118464 > opnode 0 cmult 0.4078676E+11 64159596 > opnode 0 addcl4 0.4189481E+11 106544 > opnode 0 col3 0.6824224E+11 32173287 > opnode 0 ADD2 0.8181750E+11 85243418 > opnode 0 glsc3 0.8983806E+11 228470 > opnode 0 addcl3 0.1057688E+12 63724056 > opnode 0 col2 0.2130625E+12 254874963 > opnode 0 add2s2 0.3703272E+12 1412686 > opnode 0 VLSC3 0.4606404E+12 1171469 > opnode 0 mxm 0.6246592E+13 -1613811570 > total time 34934.7607588768 34931.1205290364 > copy time 0 0.000000000000000E+000 0.000000000000000E+000 > mxmf time 0 0.000000000000000E+000 0.000000000000000E+000 > inv3 time 10344 15.3735277652740 4.401097798307057E-004 > invc time 19891515 146.002576589584 4.179727829464278E-003 > mltd time 62064 4038.74821758270 0.115620345308577 > cdtp time 15516 437.695099830627 1.253023359118396E-002 > eslv time 0 0.000000000000000E+000 0.000000000000000E+000 > pres time 5172 14242.1249115467 0.407720241888833 > crsl time 90681 47.9217271804810 1.371892068009847E-003 > crsl min 47.9217271804810 > crsl max 53.2970800399780 > crsl avg 50.6094036102295 > hmhz time 15521 15087.4339959621 0.431919553895237 > usbc time 5173 85.1574075222015 2.437866470713835E-003 > axhm time 238766 6975.35609674454 0.199688873162437 > advc time -1333526528 2.332305834658064E-310 6.676870938527185E-315 > gop time 878153 62.8719458580017 1.799883453659598E-003 > gop min 62.8719387054443 > gop max 118.545093774796 > gop avg 90.7085191011429 > vdss time 25861 108.827995061874 3.115502549407525E-003 > vdss min 108.827995061874 > vdss max 108.830206155777 > vdss avg 108.829100608826 > dsum time 334612 471.267515897751 1.349133691563118E-002 > dsum min 440.130956649780 > dsum max 471.267515897751 > dsum avg 455.699236273766 > gsum time 0 0.000000000000000E+000 0.000000000000000E+000 > dsnd time 0 0.000000000000000E+000 0.000000000000000E+000 > dadd time 0 0.000000000000000E+000 0.000000000000000E+000 > dsmx time 0 0.154825925827026 4.432320620757866E-006 > dsmn time 0 1.043796539306641E-003 2.988156473363023E-008 > slvb time 0 0.000000000000000E+000 0.000000000000000E+000 > ddsl time 0 0.000000000000000E+000 0.000000000000000E+000 > solv time 0 0.000000000000000E+000 0.000000000000000E+000 > sett time 0 0.000000000000000E+000 0.000000000000000E+000 > prep time 5173 12.7582430839539 3.652400178044276E-004 > bsol time 0 0.000000000000000E+000 0.000000000000000E+000 > bso2 time 0 0.000000000000000E+000 0.000000000000000E+000 > # nid tusbc tdadd tcrsl tvdss tdsum tgop qqq > 0 8.5157E+01 0.0000E+00 4.7922E+01 1.0883E+02 4.7127E+02 6.2872E+01 qqq > 1 8.8959E+01 0.0000E+00 5.3297E+01 1.0883E+02 4.4013E+02 1.1855E+02 qqq > > call exitt: dying ... > > backtrace(): obtained 11 stack frames. > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(print_stack_+0x26) [0x5d34ca] > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(exitt_+0x34e) [0x6eb7ce] > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(emerxit_+0x63c) [0x52deaa] > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(setdt_+0xc9a) [0x52098a] > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(settime_+0xb7) [0x4210a1] > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_advance_+0x27) [0x41d185] > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_solve_+0x2d1) [0x41d0d3] > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(MAIN__+0x3b) [0x41bfaf] > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(main+0x3c) [0x415b8c] > /lib/libc.so.6(__libc_start_main+0xda) [0x2aef191be4ca] > /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(for_write_seq_fmt_xmit+0x3a) [0x415aba] > > total elapsed time : 3.49348E+04 sec > total solver time incl. I/O : 3.49051E+04 sec > time/timestep : 6.74756E+00 sec > CPU seconds/timestep/DOF : 7.82568E-05 sec > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 14 07:42:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 14:42:46 +0200 Subject: [Nek5000-users] Example 'turbChannel' Emergency exit In-Reply-To: <6C58009F-4C89-4922-99B7-064BE8066A1E@lav.mavt.ethz.ch> References: <4BC57C0C.4000800@kit.edu> <6C58009F-4C89-4922-99B7-064BE8066A1E@lav.mavt.ethz.ch> Message-ID: <4A7A3A5D-F34D-4FD8-A49E-B52D309649E9@lav.mavt.ethz.ch> Fred, we can reproduce your problem and we try to come up with a solution soon. Stefan On Apr 14, 2010, at 10:37 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Fred, > > please attach a full logfile. > > Stefan > > > On Apr 14, 2010, at 10:25 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello NEKs, >> >> in the last day I had a couple of problems with my runs, so I started again the turbChannel example on our machine to get a better feeling for the parameters. When I run the turbChannel example, the run stopped after 5172 time steps with an 'emergency exit' cause the CFL number is getting to high. Do you know from where does this occur?? I just added the output of the last time steps. >> >> Best, >> Fred >> >> >> 5165 2.582500000E+01 3.916990657E-03 1.659821813E-03 3.694680560E-01 e2 >> Step 5166, t= 2.5830000E+01, DT= 5.0000000E-03, C= 2.079 3.4805E+04 1.3937E+01 >> Solving for fluid >> 5166 PRES alph1n 8.7741E+02 4.2415E+01 2.0687E+01 20 >> 5166 PRES halpha 20 1.1643E+01 -3.7137E+00 3.6211E-01 -2.0448E-01 -1.6916E+00 8.2524E-01 1.1625E+00 8.9342E-01 -1.6984E-01 -2.2222E-01 >> >> 5166 PRES gmres: 75 8.8674E-06 1.0000E-05 8.5433E-02 4.1833E+00 9.7743E+00 >> 5166 Hmholtz VELX: 11 1.5456E-09 1.0149E+00 1.0000E-08 >> 5166 Hmholtz VELY: 11 3.0012E-09 1.9688E+00 1.0000E-08 >> 5166 Hmholtz VELZ: 11 2.5093E-09 1.8625E+00 1.0000E-08 >> L1/L2 DIV(V) : 4.9352E-18 9.2917E-01 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: 4.9352E-18 9.2917E-01 >> WARNING: DIV(V)-QTL too large! >> 5166 2.5830E+01 1.3669E+01 Fluid done >> Calculating eddy visosity >> 5166 2.583000000E+01 3.926052513E-03 1.662276122E-03 3.689963050E-01 e2 >> Step 5167, t= 2.5835000E+01, DT= 5.0000000E-03, C= 2.889 3.4820E+04 1.4982E+01 >> Solving for fluid >> 5167 PRES alph1n 1.5542E+03 7.1980E+02 2.1591E+00 1 >> 5167 PRES halpha 1 1.4480E+01 >> 5167 PRES gmres: 86 9.7160E-06 1.0000E-05 9.3445E-01 4.7986E+00 1.1231E+01 >> 5167 Hmholtz VELX: 12 5.8389E-09 1.3413E+00 1.0000E-08 >> 5167 Hmholtz VELY: 13 3.9482E-09 2.9638E+00 1.0000E-08 >> 5167 Hmholtz VELZ: 13 3.5924E-09 2.6194E+00 1.0000E-08 >> L1/L2 DIV(V) : 3.1068E-18 1.2785E+00 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: 3.1068E-18 1.2785E+00 >> WARNING: DIV(V)-QTL too large! >> 5167 2.5835E+01 1.5275E+01 Fluid done >> Calculating eddy visosity >> 5167 2.583500000E+01 3.993359862E-03 1.664692380E-03 3.685384235E-01 e2 >> Step 5168, t= 2.5840000E+01, DT= 5.0000000E-03, C= 3.423 3.4837E+04 1.6588E+01 >> Solving for fluid >> 5168 PRES alph1n 3.9778E+03 3.8710E+03 1.0276E+00 2 >> 5168 PRES halpha 2 1.2944E+01 6.2999E-01 >> 5168 PRES gmres: 79 9.2196E-06 1.0000E-05 4.3331E+00 4.4083E+00 1.0437E+01 >> 5168 Hmholtz VELX: 14 4.7243E-09 2.0176E+00 1.0000E-08 >> 5168 Hmholtz VELY: 14 6.8219E-09 4.6788E+00 1.0000E-08 >> 5168 Hmholtz VELZ: 15 1.8252E-09 4.0913E+00 1.0000E-08 >> L1/L2 DIV(V) : -1.4831E-18 2.0942E+00 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: -1.4831E-18 2.0942E+00 >> WARNING: DIV(V)-QTL too large! >> 5168 2.5840E+01 1.4678E+01 Fluid done >> Calculating eddy visosity >> 5168 2.584000000E+01 4.200707570E-03 1.667064185E-03 3.681057305E-01 e2 >> Step 5169, t= 2.5845000E+01, DT= 5.0000000E-03, C= 5.530 3.4853E+04 1.5991E+01 >> Solving for fluid >> 5169 PRES alph1n 7.2030E+03 3.1162E+03 2.3115E+00 3 >> 5169 PRES halpha 3 -6.0424E+01 -1.0653E+01 -8.4291E+00 >> 5169 PRES gmres: 97 9.6453E-06 1.0000E-05 3.9350E+00 5.4119E+00 1.2493E+01 >> 5169 Hmholtz VELX: 11 4.1711E-09 1.9124E+00 1.0000E-08 >> 5169 Hmholtz VELY: 11 7.0818E-09 3.3758E+00 1.0000E-08 >> 5169 Hmholtz VELZ: 11 9.3833E-09 4.3104E+00 1.0000E-08 >> L1/L2 DIV(V) : 5.4916E-18 2.0864E+00 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: 5.4916E-18 2.0864E+00 >> WARNING: DIV(V)-QTL too large! >> 5169 2.5845E+01 1.6361E+01 Fluid done >> Calculating eddy visosity >> 5169 2.584500000E+01 4.167598852E-03 1.701730652E-03 3.676193877E-01 e2 >> Step 5170, t= 2.5850000E+01, DT= 5.0000000E-03, C= 6.006 3.4871E+04 1.7673E+01 >> Solving for fluid >> 5170 PRES alph1n 3.8504E+03 2.1151E+03 1.8205E+00 4 >> 5170 PRES halpha 4 -4.5903E+00 2.8727E+00 1.4775E+00 -3.0313E+01 >> 5170 PRES gmres: 95 9.5031E-06 1.0000E-05 2.9323E+00 5.3008E+00 1.2248E+01 >> 5170 Hmholtz VELX: 11 2.9823E-09 2.3489E+00 1.0000E-08 >> 5170 Hmholtz VELY: 11 5.2939E-09 5.2327E+00 1.0000E-08 >> 5170 Hmholtz VELZ: 11 8.5864E-09 6.0722E+00 1.0000E-08 >> L1/L2 DIV(V) : -1.3376E-19 1.6752E+00 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: -1.3376E-19 1.6752E+00 >> WARNING: DIV(V)-QTL too large! >> 5170 2.5850E+01 1.6120E+01 Fluid done >> Calculating eddy visosity >> 5170 2.585000000E+01 4.085734913E-03 1.716209642E-03 3.671058529E-01 e2 >> Step 5171, t= 2.5855000E+01, DT= 5.0000000E-03, C= 4.227 3.4888E+04 1.7434E+01 >> Solving for fluid >> 5171 PRES alph1n 5.0358E+03 1.2448E+03 4.0456E+00 5 >> 5171 PRES halpha 5 -6.9028E+00 -1.4184E+00 -4.2028E+01 -1.2786E+01 -2.1059E+01 >> 5171 PRES gmres: 92 9.4249E-06 1.0000E-05 1.6822E+00 5.1338E+00 1.1887E+01 >> 5171 Hmholtz VELX: 11 2.1456E-09 2.9780E+00 1.0000E-08 >> 5171 Hmholtz VELY: 11 5.3606E-09 7.0811E+00 1.0000E-08 >> 5171 Hmholtz VELZ: 11 5.8359E-09 6.8710E+00 1.0000E-08 >> L1/L2 DIV(V) : -1.6210E-17 3.1098E+00 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: -1.6210E-17 3.1098E+00 >> WARNING: DIV(V)-QTL too large! >> 5171 2.5855E+01 1.5761E+01 Fluid done >> Calculating eddy visosity >> 5171 2.585500000E+01 4.389947285E-03 1.720108719E-03 3.665677180E-01 e2 >> Step 5172, t= 2.5860000E+01, DT= 5.0000000E-03, C= 14.041 3.4905E+04 1.7076E+01 >> Solving for fluid >> 5172 PRES alph1n 9.0973E+04 3.3755E+04 2.6951E+00 6 >> 5172 PRES halpha 6 -5.1818E+02 -1.4428E+02 -8.2239E+02 -5.2616E+01 6.5613E+01 2.1168E+02 >> 5172 PRES gmres: 132 9.6516E-06 1.0000E-05 4.3975E+01 7.3637E+00 1.7181E+01 >> 5172 Hmholtz VELX: 32 8.9325E-09 4.2902E+01 1.0000E-08 >> 5172 Hmholtz VELY: 33 6.7432E-09 1.0998E+02 1.0000E-08 >> 5172 Hmholtz VELZ: 33 8.7122E-09 9.2142E+01 1.0000E-08 >> L1/L2 DIV(V) : -4.3714E-18 1.8897E+01 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: -4.3714E-18 1.8897E+01 >> WARNING: DIV(V)-QTL too large! >> 5172 2.5860E+01 2.3473E+01 Fluid done >> Calculating eddy visosity >> 5172 2.586000000E+01 4.640317048E-02 1.721776888E-03 3.660847580E-01 e2 >> CFL, Ctarg! 77.0972671240189 2.00000000000000 >> >> 5173 2.5860E+01 Write checkpoint: >> >> 5173 2.5860E+01 OPEN: turbChannel.fld06 >> >> 1 Emergency exit: 5173 time = 25.8599999999991 >> Latest solution and data are dumped for post-processing. >> *** STOP *** >> >> 0 Emergency exit: 5173 time = 25.8599999999991 >> Latest solution and data are dumped for post-processing. >> *** STOP *** >> 0 opcount 7939907566848.00 >> 1 opcount 7939907566848.00 >> TOTAL OPCOUNT 15879815133696.0 >> opnode 0 subcl4 0.000000 0 >> opnode 0 ascol5 0.000000 0 >> opnode 0 invcl3 0.1355809E+10 10344 >> opnode 0 vlsum 0.1355809E+10 2648064 >> opnode 0 inver2 0.1355809E+10 10344 >> opnode 0 cadd2 0.2033713E+10 15516 >> opnode 0 admcol 0.2033713E+10 5172 >> opnode 0 invcl1 0.2033713E+10 15516 >> opnode 0 vsqrt 0.3389915E+10 2663583 >> opnode 0 opa2cl 0.4067426E+10 5172 >> opnode 0 subcl3 0.4067426E+10 15516 >> opnode 0 sub3 0.4747952E+10 37499 >> opnode 0 sub2 0.1152359E+11 8001078 >> opnode 0 opcv3c 0.1219992E+11 15513 >> opnode 0 add3s2 0.1220228E+11 31032 >> opnode 0 VLSC2 0.1285580E+11 49041 >> opnode 0 cadd 0.1391945E+11 106197 >> opnode 0 invcl2 0.1423639E+11 19891515 >> opnode 0 opcolv 0.2643827E+11 67236 >> opnode 0 add2s1 0.2927781E+11 111686 >> opnode 0 glsc2 0.3054948E+11 116537 >> opnode 0 ADD3 0.3129265E+11 61118464 >> opnode 0 cmult 0.4078676E+11 64159596 >> opnode 0 addcl4 0.4189481E+11 106544 >> opnode 0 col3 0.6824224E+11 32173287 >> opnode 0 ADD2 0.8181750E+11 85243418 >> opnode 0 glsc3 0.8983806E+11 228470 >> opnode 0 addcl3 0.1057688E+12 63724056 >> opnode 0 col2 0.2130625E+12 254874963 >> opnode 0 add2s2 0.3703272E+12 1412686 >> opnode 0 VLSC3 0.4606404E+12 1171469 >> opnode 0 mxm 0.6246592E+13 -1613811570 >> total time 34934.7607588768 34931.1205290364 >> copy time 0 0.000000000000000E+000 0.000000000000000E+000 >> mxmf time 0 0.000000000000000E+000 0.000000000000000E+000 >> inv3 time 10344 15.3735277652740 4.401097798307057E-004 >> invc time 19891515 146.002576589584 4.179727829464278E-003 >> mltd time 62064 4038.74821758270 0.115620345308577 >> cdtp time 15516 437.695099830627 1.253023359118396E-002 >> eslv time 0 0.000000000000000E+000 0.000000000000000E+000 >> pres time 5172 14242.1249115467 0.407720241888833 >> crsl time 90681 47.9217271804810 1.371892068009847E-003 >> crsl min 47.9217271804810 >> crsl max 53.2970800399780 >> crsl avg 50.6094036102295 >> hmhz time 15521 15087.4339959621 0.431919553895237 >> usbc time 5173 85.1574075222015 2.437866470713835E-003 >> axhm time 238766 6975.35609674454 0.199688873162437 >> advc time -1333526528 2.332305834658064E-310 6.676870938527185E-315 >> gop time 878153 62.8719458580017 1.799883453659598E-003 >> gop min 62.8719387054443 >> gop max 118.545093774796 >> gop avg 90.7085191011429 >> vdss time 25861 108.827995061874 3.115502549407525E-003 >> vdss min 108.827995061874 >> vdss max 108.830206155777 >> vdss avg 108.829100608826 >> dsum time 334612 471.267515897751 1.349133691563118E-002 >> dsum min 440.130956649780 >> dsum max 471.267515897751 >> dsum avg 455.699236273766 >> gsum time 0 0.000000000000000E+000 0.000000000000000E+000 >> dsnd time 0 0.000000000000000E+000 0.000000000000000E+000 >> dadd time 0 0.000000000000000E+000 0.000000000000000E+000 >> dsmx time 0 0.154825925827026 4.432320620757866E-006 >> dsmn time 0 1.043796539306641E-003 2.988156473363023E-008 >> slvb time 0 0.000000000000000E+000 0.000000000000000E+000 >> ddsl time 0 0.000000000000000E+000 0.000000000000000E+000 >> solv time 0 0.000000000000000E+000 0.000000000000000E+000 >> sett time 0 0.000000000000000E+000 0.000000000000000E+000 >> prep time 5173 12.7582430839539 3.652400178044276E-004 >> bsol time 0 0.000000000000000E+000 0.000000000000000E+000 >> bso2 time 0 0.000000000000000E+000 0.000000000000000E+000 >> # nid tusbc tdadd tcrsl tvdss tdsum tgop qqq >> 0 8.5157E+01 0.0000E+00 4.7922E+01 1.0883E+02 4.7127E+02 6.2872E+01 qqq >> 1 8.8959E+01 0.0000E+00 5.3297E+01 1.0883E+02 4.4013E+02 1.1855E+02 qqq >> >> call exitt: dying ... >> >> backtrace(): obtained 11 stack frames. >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(print_stack_+0x26) [0x5d34ca] >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(exitt_+0x34e) [0x6eb7ce] >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(emerxit_+0x63c) [0x52deaa] >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(setdt_+0xc9a) [0x52098a] >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(settime_+0xb7) [0x4210a1] >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_advance_+0x27) [0x41d185] >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_solve_+0x2d1) [0x41d0d3] >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(MAIN__+0x3b) [0x41bfaf] >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(main+0x3c) [0x415b8c] >> /lib/libc.so.6(__libc_start_main+0xda) [0x2aef191be4ca] >> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(for_write_seq_fmt_xmit+0x3a) [0x415aba] >> >> total elapsed time : 3.49348E+04 sec >> total solver time incl. I/O : 3.49051E+04 sec >> time/timestep : 6.74756E+00 sec >> CPU seconds/timestep/DOF : 7.82568E-05 sec >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 14 08:28:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 15:28:34 +0200 Subject: [Nek5000-users] Example 'turbChannel' Emergency exit In-Reply-To: <4A7A3A5D-F34D-4FD8-A49E-B52D309649E9@lav.mavt.ethz.ch> References: <4A7A3A5D-F34D-4FD8-A49E-B52D309649E9@lav.mavt.ethz.ch> Message-ID: <4BC5C302.5050009@kit.edu> Thanks a lot!!! From nek5000-users at lists.mcs.anl.gov Wed Apr 14 09:16:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 16:16:25 +0200 Subject: [Nek5000-users] Example 'turbChannel' Emergency exit In-Reply-To: <4A7A3A5D-F34D-4FD8-A49E-B52D309649E9@lav.mavt.ethz.ch> References: <4BC57C0C.4000800@kit.edu> <6C58009F-4C89-4922-99B7-064BE8066A1E@lav.mavt.ethz.ch> <4A7A3A5D-F34D-4FD8-A49E-B52D309649E9@lav.mavt.ethz.ch> Message-ID: Fred, for now just disable the dynamic Smagorinski model e.g. set param(30) = 0! Instead the simple filtering SGS model is used. Two parameters are important here: param(101) ... additional modes to filter param(103) ... filter weight of the last mode Typically a good starting point is p101=1 and p103=0.05. -Stefan On Apr 14, 2010, at 2:42 PM, nek5000-users at lists.mcs.anl.gov wrote: > Fred, > > we can reproduce your problem and we try to come up with a solution soon. > > Stefan > > > On Apr 14, 2010, at 10:37 AM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Fred, >> >> please attach a full logfile. >> >> Stefan >> >> >> On Apr 14, 2010, at 10:25 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello NEKs, >>> >>> in the last day I had a couple of problems with my runs, so I started again the turbChannel example on our machine to get a better feeling for the parameters. When I run the turbChannel example, the run stopped after 5172 time steps with an 'emergency exit' cause the CFL number is getting to high. Do you know from where does this occur?? I just added the output of the last time steps. >>> >>> Best, >>> Fred >>> >>> >>> 5165 2.582500000E+01 3.916990657E-03 1.659821813E-03 3.694680560E-01 e2 >>> Step 5166, t= 2.5830000E+01, DT= 5.0000000E-03, C= 2.079 3.4805E+04 1.3937E+01 >>> Solving for fluid >>> 5166 PRES alph1n 8.7741E+02 4.2415E+01 2.0687E+01 20 >>> 5166 PRES halpha 20 1.1643E+01 -3.7137E+00 3.6211E-01 -2.0448E-01 -1.6916E+00 8.2524E-01 1.1625E+00 8.9342E-01 -1.6984E-01 -2.2222E-01 >>> >>> 5166 PRES gmres: 75 8.8674E-06 1.0000E-05 8.5433E-02 4.1833E+00 9.7743E+00 >>> 5166 Hmholtz VELX: 11 1.5456E-09 1.0149E+00 1.0000E-08 >>> 5166 Hmholtz VELY: 11 3.0012E-09 1.9688E+00 1.0000E-08 >>> 5166 Hmholtz VELZ: 11 2.5093E-09 1.8625E+00 1.0000E-08 >>> L1/L2 DIV(V) : 4.9352E-18 9.2917E-01 >>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>> L1/L2 DIV(V)-QTL: 4.9352E-18 9.2917E-01 >>> WARNING: DIV(V)-QTL too large! >>> 5166 2.5830E+01 1.3669E+01 Fluid done >>> Calculating eddy visosity >>> 5166 2.583000000E+01 3.926052513E-03 1.662276122E-03 3.689963050E-01 e2 >>> Step 5167, t= 2.5835000E+01, DT= 5.0000000E-03, C= 2.889 3.4820E+04 1.4982E+01 >>> Solving for fluid >>> 5167 PRES alph1n 1.5542E+03 7.1980E+02 2.1591E+00 1 >>> 5167 PRES halpha 1 1.4480E+01 >>> 5167 PRES gmres: 86 9.7160E-06 1.0000E-05 9.3445E-01 4.7986E+00 1.1231E+01 >>> 5167 Hmholtz VELX: 12 5.8389E-09 1.3413E+00 1.0000E-08 >>> 5167 Hmholtz VELY: 13 3.9482E-09 2.9638E+00 1.0000E-08 >>> 5167 Hmholtz VELZ: 13 3.5924E-09 2.6194E+00 1.0000E-08 >>> L1/L2 DIV(V) : 3.1068E-18 1.2785E+00 >>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>> L1/L2 DIV(V)-QTL: 3.1068E-18 1.2785E+00 >>> WARNING: DIV(V)-QTL too large! >>> 5167 2.5835E+01 1.5275E+01 Fluid done >>> Calculating eddy visosity >>> 5167 2.583500000E+01 3.993359862E-03 1.664692380E-03 3.685384235E-01 e2 >>> Step 5168, t= 2.5840000E+01, DT= 5.0000000E-03, C= 3.423 3.4837E+04 1.6588E+01 >>> Solving for fluid >>> 5168 PRES alph1n 3.9778E+03 3.8710E+03 1.0276E+00 2 >>> 5168 PRES halpha 2 1.2944E+01 6.2999E-01 >>> 5168 PRES gmres: 79 9.2196E-06 1.0000E-05 4.3331E+00 4.4083E+00 1.0437E+01 >>> 5168 Hmholtz VELX: 14 4.7243E-09 2.0176E+00 1.0000E-08 >>> 5168 Hmholtz VELY: 14 6.8219E-09 4.6788E+00 1.0000E-08 >>> 5168 Hmholtz VELZ: 15 1.8252E-09 4.0913E+00 1.0000E-08 >>> L1/L2 DIV(V) : -1.4831E-18 2.0942E+00 >>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>> L1/L2 DIV(V)-QTL: -1.4831E-18 2.0942E+00 >>> WARNING: DIV(V)-QTL too large! >>> 5168 2.5840E+01 1.4678E+01 Fluid done >>> Calculating eddy visosity >>> 5168 2.584000000E+01 4.200707570E-03 1.667064185E-03 3.681057305E-01 e2 >>> Step 5169, t= 2.5845000E+01, DT= 5.0000000E-03, C= 5.530 3.4853E+04 1.5991E+01 >>> Solving for fluid >>> 5169 PRES alph1n 7.2030E+03 3.1162E+03 2.3115E+00 3 >>> 5169 PRES halpha 3 -6.0424E+01 -1.0653E+01 -8.4291E+00 >>> 5169 PRES gmres: 97 9.6453E-06 1.0000E-05 3.9350E+00 5.4119E+00 1.2493E+01 >>> 5169 Hmholtz VELX: 11 4.1711E-09 1.9124E+00 1.0000E-08 >>> 5169 Hmholtz VELY: 11 7.0818E-09 3.3758E+00 1.0000E-08 >>> 5169 Hmholtz VELZ: 11 9.3833E-09 4.3104E+00 1.0000E-08 >>> L1/L2 DIV(V) : 5.4916E-18 2.0864E+00 >>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>> L1/L2 DIV(V)-QTL: 5.4916E-18 2.0864E+00 >>> WARNING: DIV(V)-QTL too large! >>> 5169 2.5845E+01 1.6361E+01 Fluid done >>> Calculating eddy visosity >>> 5169 2.584500000E+01 4.167598852E-03 1.701730652E-03 3.676193877E-01 e2 >>> Step 5170, t= 2.5850000E+01, DT= 5.0000000E-03, C= 6.006 3.4871E+04 1.7673E+01 >>> Solving for fluid >>> 5170 PRES alph1n 3.8504E+03 2.1151E+03 1.8205E+00 4 >>> 5170 PRES halpha 4 -4.5903E+00 2.8727E+00 1.4775E+00 -3.0313E+01 >>> 5170 PRES gmres: 95 9.5031E-06 1.0000E-05 2.9323E+00 5.3008E+00 1.2248E+01 >>> 5170 Hmholtz VELX: 11 2.9823E-09 2.3489E+00 1.0000E-08 >>> 5170 Hmholtz VELY: 11 5.2939E-09 5.2327E+00 1.0000E-08 >>> 5170 Hmholtz VELZ: 11 8.5864E-09 6.0722E+00 1.0000E-08 >>> L1/L2 DIV(V) : -1.3376E-19 1.6752E+00 >>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>> L1/L2 DIV(V)-QTL: -1.3376E-19 1.6752E+00 >>> WARNING: DIV(V)-QTL too large! >>> 5170 2.5850E+01 1.6120E+01 Fluid done >>> Calculating eddy visosity >>> 5170 2.585000000E+01 4.085734913E-03 1.716209642E-03 3.671058529E-01 e2 >>> Step 5171, t= 2.5855000E+01, DT= 5.0000000E-03, C= 4.227 3.4888E+04 1.7434E+01 >>> Solving for fluid >>> 5171 PRES alph1n 5.0358E+03 1.2448E+03 4.0456E+00 5 >>> 5171 PRES halpha 5 -6.9028E+00 -1.4184E+00 -4.2028E+01 -1.2786E+01 -2.1059E+01 >>> 5171 PRES gmres: 92 9.4249E-06 1.0000E-05 1.6822E+00 5.1338E+00 1.1887E+01 >>> 5171 Hmholtz VELX: 11 2.1456E-09 2.9780E+00 1.0000E-08 >>> 5171 Hmholtz VELY: 11 5.3606E-09 7.0811E+00 1.0000E-08 >>> 5171 Hmholtz VELZ: 11 5.8359E-09 6.8710E+00 1.0000E-08 >>> L1/L2 DIV(V) : -1.6210E-17 3.1098E+00 >>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>> L1/L2 DIV(V)-QTL: -1.6210E-17 3.1098E+00 >>> WARNING: DIV(V)-QTL too large! >>> 5171 2.5855E+01 1.5761E+01 Fluid done >>> Calculating eddy visosity >>> 5171 2.585500000E+01 4.389947285E-03 1.720108719E-03 3.665677180E-01 e2 >>> Step 5172, t= 2.5860000E+01, DT= 5.0000000E-03, C= 14.041 3.4905E+04 1.7076E+01 >>> Solving for fluid >>> 5172 PRES alph1n 9.0973E+04 3.3755E+04 2.6951E+00 6 >>> 5172 PRES halpha 6 -5.1818E+02 -1.4428E+02 -8.2239E+02 -5.2616E+01 6.5613E+01 2.1168E+02 >>> 5172 PRES gmres: 132 9.6516E-06 1.0000E-05 4.3975E+01 7.3637E+00 1.7181E+01 >>> 5172 Hmholtz VELX: 32 8.9325E-09 4.2902E+01 1.0000E-08 >>> 5172 Hmholtz VELY: 33 6.7432E-09 1.0998E+02 1.0000E-08 >>> 5172 Hmholtz VELZ: 33 8.7122E-09 9.2142E+01 1.0000E-08 >>> L1/L2 DIV(V) : -4.3714E-18 1.8897E+01 >>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>> L1/L2 DIV(V)-QTL: -4.3714E-18 1.8897E+01 >>> WARNING: DIV(V)-QTL too large! >>> 5172 2.5860E+01 2.3473E+01 Fluid done >>> Calculating eddy visosity >>> 5172 2.586000000E+01 4.640317048E-02 1.721776888E-03 3.660847580E-01 e2 >>> CFL, Ctarg! 77.0972671240189 2.00000000000000 >>> >>> 5173 2.5860E+01 Write checkpoint: >>> >>> 5173 2.5860E+01 OPEN: turbChannel.fld06 >>> >>> 1 Emergency exit: 5173 time = 25.8599999999991 >>> Latest solution and data are dumped for post-processing. >>> *** STOP *** >>> >>> 0 Emergency exit: 5173 time = 25.8599999999991 >>> Latest solution and data are dumped for post-processing. >>> *** STOP *** >>> 0 opcount 7939907566848.00 >>> 1 opcount 7939907566848.00 >>> TOTAL OPCOUNT 15879815133696.0 >>> opnode 0 subcl4 0.000000 0 >>> opnode 0 ascol5 0.000000 0 >>> opnode 0 invcl3 0.1355809E+10 10344 >>> opnode 0 vlsum 0.1355809E+10 2648064 >>> opnode 0 inver2 0.1355809E+10 10344 >>> opnode 0 cadd2 0.2033713E+10 15516 >>> opnode 0 admcol 0.2033713E+10 5172 >>> opnode 0 invcl1 0.2033713E+10 15516 >>> opnode 0 vsqrt 0.3389915E+10 2663583 >>> opnode 0 opa2cl 0.4067426E+10 5172 >>> opnode 0 subcl3 0.4067426E+10 15516 >>> opnode 0 sub3 0.4747952E+10 37499 >>> opnode 0 sub2 0.1152359E+11 8001078 >>> opnode 0 opcv3c 0.1219992E+11 15513 >>> opnode 0 add3s2 0.1220228E+11 31032 >>> opnode 0 VLSC2 0.1285580E+11 49041 >>> opnode 0 cadd 0.1391945E+11 106197 >>> opnode 0 invcl2 0.1423639E+11 19891515 >>> opnode 0 opcolv 0.2643827E+11 67236 >>> opnode 0 add2s1 0.2927781E+11 111686 >>> opnode 0 glsc2 0.3054948E+11 116537 >>> opnode 0 ADD3 0.3129265E+11 61118464 >>> opnode 0 cmult 0.4078676E+11 64159596 >>> opnode 0 addcl4 0.4189481E+11 106544 >>> opnode 0 col3 0.6824224E+11 32173287 >>> opnode 0 ADD2 0.8181750E+11 85243418 >>> opnode 0 glsc3 0.8983806E+11 228470 >>> opnode 0 addcl3 0.1057688E+12 63724056 >>> opnode 0 col2 0.2130625E+12 254874963 >>> opnode 0 add2s2 0.3703272E+12 1412686 >>> opnode 0 VLSC3 0.4606404E+12 1171469 >>> opnode 0 mxm 0.6246592E+13 -1613811570 >>> total time 34934.7607588768 34931.1205290364 >>> copy time 0 0.000000000000000E+000 0.000000000000000E+000 >>> mxmf time 0 0.000000000000000E+000 0.000000000000000E+000 >>> inv3 time 10344 15.3735277652740 4.401097798307057E-004 >>> invc time 19891515 146.002576589584 4.179727829464278E-003 >>> mltd time 62064 4038.74821758270 0.115620345308577 >>> cdtp time 15516 437.695099830627 1.253023359118396E-002 >>> eslv time 0 0.000000000000000E+000 0.000000000000000E+000 >>> pres time 5172 14242.1249115467 0.407720241888833 >>> crsl time 90681 47.9217271804810 1.371892068009847E-003 >>> crsl min 47.9217271804810 >>> crsl max 53.2970800399780 >>> crsl avg 50.6094036102295 >>> hmhz time 15521 15087.4339959621 0.431919553895237 >>> usbc time 5173 85.1574075222015 2.437866470713835E-003 >>> axhm time 238766 6975.35609674454 0.199688873162437 >>> advc time -1333526528 2.332305834658064E-310 6.676870938527185E-315 >>> gop time 878153 62.8719458580017 1.799883453659598E-003 >>> gop min 62.8719387054443 >>> gop max 118.545093774796 >>> gop avg 90.7085191011429 >>> vdss time 25861 108.827995061874 3.115502549407525E-003 >>> vdss min 108.827995061874 >>> vdss max 108.830206155777 >>> vdss avg 108.829100608826 >>> dsum time 334612 471.267515897751 1.349133691563118E-002 >>> dsum min 440.130956649780 >>> dsum max 471.267515897751 >>> dsum avg 455.699236273766 >>> gsum time 0 0.000000000000000E+000 0.000000000000000E+000 >>> dsnd time 0 0.000000000000000E+000 0.000000000000000E+000 >>> dadd time 0 0.000000000000000E+000 0.000000000000000E+000 >>> dsmx time 0 0.154825925827026 4.432320620757866E-006 >>> dsmn time 0 1.043796539306641E-003 2.988156473363023E-008 >>> slvb time 0 0.000000000000000E+000 0.000000000000000E+000 >>> ddsl time 0 0.000000000000000E+000 0.000000000000000E+000 >>> solv time 0 0.000000000000000E+000 0.000000000000000E+000 >>> sett time 0 0.000000000000000E+000 0.000000000000000E+000 >>> prep time 5173 12.7582430839539 3.652400178044276E-004 >>> bsol time 0 0.000000000000000E+000 0.000000000000000E+000 >>> bso2 time 0 0.000000000000000E+000 0.000000000000000E+000 >>> # nid tusbc tdadd tcrsl tvdss tdsum tgop qqq >>> 0 8.5157E+01 0.0000E+00 4.7922E+01 1.0883E+02 4.7127E+02 6.2872E+01 qqq >>> 1 8.8959E+01 0.0000E+00 5.3297E+01 1.0883E+02 4.4013E+02 1.1855E+02 qqq >>> >>> call exitt: dying ... >>> >>> backtrace(): obtained 11 stack frames. >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(print_stack_+0x26) [0x5d34ca] >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(exitt_+0x34e) [0x6eb7ce] >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(emerxit_+0x63c) [0x52deaa] >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(setdt_+0xc9a) [0x52098a] >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(settime_+0xb7) [0x4210a1] >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_advance_+0x27) [0x41d185] >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_solve_+0x2d1) [0x41d0d3] >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(MAIN__+0x3b) [0x41bfaf] >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(main+0x3c) [0x415b8c] >>> /lib/libc.so.6(__libc_start_main+0xda) [0x2aef191be4ca] >>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(for_write_seq_fmt_xmit+0x3a) [0x415aba] >>> >>> total elapsed time : 3.49348E+04 sec >>> total solver time incl. I/O : 3.49051E+04 sec >>> time/timestep : 6.74756E+00 sec >>> CPU seconds/timestep/DOF : 7.82568E-05 sec >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 14 09:26:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 09:26:25 -0500 (CDT) Subject: [Nek5000-users] Example 'turbChannel' Emergency exit In-Reply-To: References: <4BC57C0C.4000800@kit.edu> <6C58009F-4C89-4922-99B7-064BE8066A1E@lav.mavt.ethz.ch> <4A7A3A5D-F34D-4FD8-A49E-B52D309649E9@lav.mavt.ethz.ch> Message-ID: I'm not too familiar with this particular setup, but in my past LES experience I find one needs a significant reduction in dt in the passage through transition to the fully turbulent state. Looking at the e2 quanity ( grep e2 logfile > t.2; gnuplot, plot 't.2' u 2:3 w l ), I see that it looks like the simulation is getting to that point... Just an observation... Paul On Wed, 14 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Fred, > > for now just disable the dynamic Smagorinski model e.g. set param(30) = 0! > Instead the simple filtering SGS model is used. Two parameters are important here: > > param(101) ... additional modes to filter > param(103) ... filter weight of the last mode > > Typically a good starting point is p101=1 and p103=0.05. > > -Stefan > > > On Apr 14, 2010, at 2:42 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Fred, >> >> we can reproduce your problem and we try to come up with a solution soon. >> >> Stefan >> >> >> On Apr 14, 2010, at 10:37 AM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Fred, >>> >>> please attach a full logfile. >>> >>> Stefan >>> >>> >>> On Apr 14, 2010, at 10:25 AM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello NEKs, >>>> >>>> in the last day I had a couple of problems with my runs, so I started again the turbChannel example on our machine to get a better feeling for the parameters. When I run the turbChannel example, the run stopped after 5172 time steps with an 'emergency exit' cause the CFL number is getting to high. Do you know from where does this occur?? I just added the output of the last time steps. >>>> >>>> Best, >>>> Fred >>>> >>>> >>>> 5165 2.582500000E+01 3.916990657E-03 1.659821813E-03 3.694680560E-01 e2 >>>> Step 5166, t= 2.5830000E+01, DT= 5.0000000E-03, C= 2.079 3.4805E+04 1.3937E+01 >>>> Solving for fluid >>>> 5166 PRES alph1n 8.7741E+02 4.2415E+01 2.0687E+01 20 >>>> 5166 PRES halpha 20 1.1643E+01 -3.7137E+00 3.6211E-01 -2.0448E-01 -1.6916E+00 8.2524E-01 1.1625E+00 8.9342E-01 -1.6984E-01 -2.2222E-01 >>>> >>>> 5166 PRES gmres: 75 8.8674E-06 1.0000E-05 8.5433E-02 4.1833E+00 9.7743E+00 >>>> 5166 Hmholtz VELX: 11 1.5456E-09 1.0149E+00 1.0000E-08 >>>> 5166 Hmholtz VELY: 11 3.0012E-09 1.9688E+00 1.0000E-08 >>>> 5166 Hmholtz VELZ: 11 2.5093E-09 1.8625E+00 1.0000E-08 >>>> L1/L2 DIV(V) : 4.9352E-18 9.2917E-01 >>>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>>> L1/L2 DIV(V)-QTL: 4.9352E-18 9.2917E-01 >>>> WARNING: DIV(V)-QTL too large! >>>> 5166 2.5830E+01 1.3669E+01 Fluid done >>>> Calculating eddy visosity >>>> 5166 2.583000000E+01 3.926052513E-03 1.662276122E-03 3.689963050E-01 e2 >>>> Step 5167, t= 2.5835000E+01, DT= 5.0000000E-03, C= 2.889 3.4820E+04 1.4982E+01 >>>> Solving for fluid >>>> 5167 PRES alph1n 1.5542E+03 7.1980E+02 2.1591E+00 1 >>>> 5167 PRES halpha 1 1.4480E+01 >>>> 5167 PRES gmres: 86 9.7160E-06 1.0000E-05 9.3445E-01 4.7986E+00 1.1231E+01 >>>> 5167 Hmholtz VELX: 12 5.8389E-09 1.3413E+00 1.0000E-08 >>>> 5167 Hmholtz VELY: 13 3.9482E-09 2.9638E+00 1.0000E-08 >>>> 5167 Hmholtz VELZ: 13 3.5924E-09 2.6194E+00 1.0000E-08 >>>> L1/L2 DIV(V) : 3.1068E-18 1.2785E+00 >>>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>>> L1/L2 DIV(V)-QTL: 3.1068E-18 1.2785E+00 >>>> WARNING: DIV(V)-QTL too large! >>>> 5167 2.5835E+01 1.5275E+01 Fluid done >>>> Calculating eddy visosity >>>> 5167 2.583500000E+01 3.993359862E-03 1.664692380E-03 3.685384235E-01 e2 >>>> Step 5168, t= 2.5840000E+01, DT= 5.0000000E-03, C= 3.423 3.4837E+04 1.6588E+01 >>>> Solving for fluid >>>> 5168 PRES alph1n 3.9778E+03 3.8710E+03 1.0276E+00 2 >>>> 5168 PRES halpha 2 1.2944E+01 6.2999E-01 >>>> 5168 PRES gmres: 79 9.2196E-06 1.0000E-05 4.3331E+00 4.4083E+00 1.0437E+01 >>>> 5168 Hmholtz VELX: 14 4.7243E-09 2.0176E+00 1.0000E-08 >>>> 5168 Hmholtz VELY: 14 6.8219E-09 4.6788E+00 1.0000E-08 >>>> 5168 Hmholtz VELZ: 15 1.8252E-09 4.0913E+00 1.0000E-08 >>>> L1/L2 DIV(V) : -1.4831E-18 2.0942E+00 >>>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>>> L1/L2 DIV(V)-QTL: -1.4831E-18 2.0942E+00 >>>> WARNING: DIV(V)-QTL too large! >>>> 5168 2.5840E+01 1.4678E+01 Fluid done >>>> Calculating eddy visosity >>>> 5168 2.584000000E+01 4.200707570E-03 1.667064185E-03 3.681057305E-01 e2 >>>> Step 5169, t= 2.5845000E+01, DT= 5.0000000E-03, C= 5.530 3.4853E+04 1.5991E+01 >>>> Solving for fluid >>>> 5169 PRES alph1n 7.2030E+03 3.1162E+03 2.3115E+00 3 >>>> 5169 PRES halpha 3 -6.0424E+01 -1.0653E+01 -8.4291E+00 >>>> 5169 PRES gmres: 97 9.6453E-06 1.0000E-05 3.9350E+00 5.4119E+00 1.2493E+01 >>>> 5169 Hmholtz VELX: 11 4.1711E-09 1.9124E+00 1.0000E-08 >>>> 5169 Hmholtz VELY: 11 7.0818E-09 3.3758E+00 1.0000E-08 >>>> 5169 Hmholtz VELZ: 11 9.3833E-09 4.3104E+00 1.0000E-08 >>>> L1/L2 DIV(V) : 5.4916E-18 2.0864E+00 >>>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>>> L1/L2 DIV(V)-QTL: 5.4916E-18 2.0864E+00 >>>> WARNING: DIV(V)-QTL too large! >>>> 5169 2.5845E+01 1.6361E+01 Fluid done >>>> Calculating eddy visosity >>>> 5169 2.584500000E+01 4.167598852E-03 1.701730652E-03 3.676193877E-01 e2 >>>> Step 5170, t= 2.5850000E+01, DT= 5.0000000E-03, C= 6.006 3.4871E+04 1.7673E+01 >>>> Solving for fluid >>>> 5170 PRES alph1n 3.8504E+03 2.1151E+03 1.8205E+00 4 >>>> 5170 PRES halpha 4 -4.5903E+00 2.8727E+00 1.4775E+00 -3.0313E+01 >>>> 5170 PRES gmres: 95 9.5031E-06 1.0000E-05 2.9323E+00 5.3008E+00 1.2248E+01 >>>> 5170 Hmholtz VELX: 11 2.9823E-09 2.3489E+00 1.0000E-08 >>>> 5170 Hmholtz VELY: 11 5.2939E-09 5.2327E+00 1.0000E-08 >>>> 5170 Hmholtz VELZ: 11 8.5864E-09 6.0722E+00 1.0000E-08 >>>> L1/L2 DIV(V) : -1.3376E-19 1.6752E+00 >>>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>>> L1/L2 DIV(V)-QTL: -1.3376E-19 1.6752E+00 >>>> WARNING: DIV(V)-QTL too large! >>>> 5170 2.5850E+01 1.6120E+01 Fluid done >>>> Calculating eddy visosity >>>> 5170 2.585000000E+01 4.085734913E-03 1.716209642E-03 3.671058529E-01 e2 >>>> Step 5171, t= 2.5855000E+01, DT= 5.0000000E-03, C= 4.227 3.4888E+04 1.7434E+01 >>>> Solving for fluid >>>> 5171 PRES alph1n 5.0358E+03 1.2448E+03 4.0456E+00 5 >>>> 5171 PRES halpha 5 -6.9028E+00 -1.4184E+00 -4.2028E+01 -1.2786E+01 -2.1059E+01 >>>> 5171 PRES gmres: 92 9.4249E-06 1.0000E-05 1.6822E+00 5.1338E+00 1.1887E+01 >>>> 5171 Hmholtz VELX: 11 2.1456E-09 2.9780E+00 1.0000E-08 >>>> 5171 Hmholtz VELY: 11 5.3606E-09 7.0811E+00 1.0000E-08 >>>> 5171 Hmholtz VELZ: 11 5.8359E-09 6.8710E+00 1.0000E-08 >>>> L1/L2 DIV(V) : -1.6210E-17 3.1098E+00 >>>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>>> L1/L2 DIV(V)-QTL: -1.6210E-17 3.1098E+00 >>>> WARNING: DIV(V)-QTL too large! >>>> 5171 2.5855E+01 1.5761E+01 Fluid done >>>> Calculating eddy visosity >>>> 5171 2.585500000E+01 4.389947285E-03 1.720108719E-03 3.665677180E-01 e2 >>>> Step 5172, t= 2.5860000E+01, DT= 5.0000000E-03, C= 14.041 3.4905E+04 1.7076E+01 >>>> Solving for fluid >>>> 5172 PRES alph1n 9.0973E+04 3.3755E+04 2.6951E+00 6 >>>> 5172 PRES halpha 6 -5.1818E+02 -1.4428E+02 -8.2239E+02 -5.2616E+01 6.5613E+01 2.1168E+02 >>>> 5172 PRES gmres: 132 9.6516E-06 1.0000E-05 4.3975E+01 7.3637E+00 1.7181E+01 >>>> 5172 Hmholtz VELX: 32 8.9325E-09 4.2902E+01 1.0000E-08 >>>> 5172 Hmholtz VELY: 33 6.7432E-09 1.0998E+02 1.0000E-08 >>>> 5172 Hmholtz VELZ: 33 8.7122E-09 9.2142E+01 1.0000E-08 >>>> L1/L2 DIV(V) : -4.3714E-18 1.8897E+01 >>>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>>> L1/L2 DIV(V)-QTL: -4.3714E-18 1.8897E+01 >>>> WARNING: DIV(V)-QTL too large! >>>> 5172 2.5860E+01 2.3473E+01 Fluid done >>>> Calculating eddy visosity >>>> 5172 2.586000000E+01 4.640317048E-02 1.721776888E-03 3.660847580E-01 e2 >>>> CFL, Ctarg! 77.0972671240189 2.00000000000000 >>>> >>>> 5173 2.5860E+01 Write checkpoint: >>>> >>>> 5173 2.5860E+01 OPEN: turbChannel.fld06 >>>> >>>> 1 Emergency exit: 5173 time = 25.8599999999991 >>>> Latest solution and data are dumped for post-processing. >>>> *** STOP *** >>>> >>>> 0 Emergency exit: 5173 time = 25.8599999999991 >>>> Latest solution and data are dumped for post-processing. >>>> *** STOP *** >>>> 0 opcount 7939907566848.00 >>>> 1 opcount 7939907566848.00 >>>> TOTAL OPCOUNT 15879815133696.0 >>>> opnode 0 subcl4 0.000000 0 >>>> opnode 0 ascol5 0.000000 0 >>>> opnode 0 invcl3 0.1355809E+10 10344 >>>> opnode 0 vlsum 0.1355809E+10 2648064 >>>> opnode 0 inver2 0.1355809E+10 10344 >>>> opnode 0 cadd2 0.2033713E+10 15516 >>>> opnode 0 admcol 0.2033713E+10 5172 >>>> opnode 0 invcl1 0.2033713E+10 15516 >>>> opnode 0 vsqrt 0.3389915E+10 2663583 >>>> opnode 0 opa2cl 0.4067426E+10 5172 >>>> opnode 0 subcl3 0.4067426E+10 15516 >>>> opnode 0 sub3 0.4747952E+10 37499 >>>> opnode 0 sub2 0.1152359E+11 8001078 >>>> opnode 0 opcv3c 0.1219992E+11 15513 >>>> opnode 0 add3s2 0.1220228E+11 31032 >>>> opnode 0 VLSC2 0.1285580E+11 49041 >>>> opnode 0 cadd 0.1391945E+11 106197 >>>> opnode 0 invcl2 0.1423639E+11 19891515 >>>> opnode 0 opcolv 0.2643827E+11 67236 >>>> opnode 0 add2s1 0.2927781E+11 111686 >>>> opnode 0 glsc2 0.3054948E+11 116537 >>>> opnode 0 ADD3 0.3129265E+11 61118464 >>>> opnode 0 cmult 0.4078676E+11 64159596 >>>> opnode 0 addcl4 0.4189481E+11 106544 >>>> opnode 0 col3 0.6824224E+11 32173287 >>>> opnode 0 ADD2 0.8181750E+11 85243418 >>>> opnode 0 glsc3 0.8983806E+11 228470 >>>> opnode 0 addcl3 0.1057688E+12 63724056 >>>> opnode 0 col2 0.2130625E+12 254874963 >>>> opnode 0 add2s2 0.3703272E+12 1412686 >>>> opnode 0 VLSC3 0.4606404E+12 1171469 >>>> opnode 0 mxm 0.6246592E+13 -1613811570 >>>> total time 34934.7607588768 34931.1205290364 >>>> copy time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> mxmf time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> inv3 time 10344 15.3735277652740 4.401097798307057E-004 >>>> invc time 19891515 146.002576589584 4.179727829464278E-003 >>>> mltd time 62064 4038.74821758270 0.115620345308577 >>>> cdtp time 15516 437.695099830627 1.253023359118396E-002 >>>> eslv time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> pres time 5172 14242.1249115467 0.407720241888833 >>>> crsl time 90681 47.9217271804810 1.371892068009847E-003 >>>> crsl min 47.9217271804810 >>>> crsl max 53.2970800399780 >>>> crsl avg 50.6094036102295 >>>> hmhz time 15521 15087.4339959621 0.431919553895237 >>>> usbc time 5173 85.1574075222015 2.437866470713835E-003 >>>> axhm time 238766 6975.35609674454 0.199688873162437 >>>> advc time -1333526528 2.332305834658064E-310 6.676870938527185E-315 >>>> gop time 878153 62.8719458580017 1.799883453659598E-003 >>>> gop min 62.8719387054443 >>>> gop max 118.545093774796 >>>> gop avg 90.7085191011429 >>>> vdss time 25861 108.827995061874 3.115502549407525E-003 >>>> vdss min 108.827995061874 >>>> vdss max 108.830206155777 >>>> vdss avg 108.829100608826 >>>> dsum time 334612 471.267515897751 1.349133691563118E-002 >>>> dsum min 440.130956649780 >>>> dsum max 471.267515897751 >>>> dsum avg 455.699236273766 >>>> gsum time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> dsnd time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> dadd time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> dsmx time 0 0.154825925827026 4.432320620757866E-006 >>>> dsmn time 0 1.043796539306641E-003 2.988156473363023E-008 >>>> slvb time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> ddsl time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> solv time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> sett time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> prep time 5173 12.7582430839539 3.652400178044276E-004 >>>> bsol time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> bso2 time 0 0.000000000000000E+000 0.000000000000000E+000 >>>> # nid tusbc tdadd tcrsl tvdss tdsum tgop qqq >>>> 0 8.5157E+01 0.0000E+00 4.7922E+01 1.0883E+02 4.7127E+02 6.2872E+01 qqq >>>> 1 8.8959E+01 0.0000E+00 5.3297E+01 1.0883E+02 4.4013E+02 1.1855E+02 qqq >>>> >>>> call exitt: dying ... >>>> >>>> backtrace(): obtained 11 stack frames. >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(print_stack_+0x26) [0x5d34ca] >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(exitt_+0x34e) [0x6eb7ce] >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(emerxit_+0x63c) [0x52deaa] >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(setdt_+0xc9a) [0x52098a] >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(settime_+0xb7) [0x4210a1] >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_advance_+0x27) [0x41d185] >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(nek_solve_+0x2d1) [0x41d0d3] >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(MAIN__+0x3b) [0x41bfaf] >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(main+0x3c) [0x415b8c] >>>> /lib/libc.so.6(__libc_start_main+0xda) [0x2aef191be4ca] >>>> /data2/DATEN/frederik/nek5/examples/turbChannel/nek5000(for_write_seq_fmt_xmit+0x3a) [0x415aba] >>>> >>>> total elapsed time : 3.49348E+04 sec >>>> total solver time incl. I/O : 3.49051E+04 sec >>>> time/timestep : 6.74756E+00 sec >>>> CPU seconds/timestep/DOF : 7.82568E-05 sec >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Apr 14 11:54:47 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 11:54:47 -0500 Subject: [Nek5000-users] Calculating wall shear stress and dimensionless wall distances Message-ID: Dear Paul, Thank you for the reply. I tried to implement the code in the usrchk subroutine but found that the values of dgtq and dg are zeros. I tried to identify the wall boundary conditions and found the corresponding the elements , faces and used the code snippet. I am sure I am missing something here.. Any thoughts ? However the way you said with the postx works. It did give me a profile.out and I am currently working on a way to post-process it. I have close to 25k elements and probably a few hundred elements near the blade and I am not quite sure how to grab the coordinates to enter into the prof.in file. Ideally I would like to get the yplus/z plus for the first couple of elements or so. I tried the same way of grabbing the elements and faces near the area of interest, but I am clueless as to how I access the co-ordinate data of those elements. I had another question regarding span-wise averaging of shear stress, Once I calculate the shear stress using the above routine, could I use the z_average() routine in navier5.f to do the span-wise averaging ? I was looking at the turbchannel.usr where the wall shear stress and averaging process is done but did not make a huge progress.. subroutine usrchk include 'SIZE' include 'TOTAL' include 'ZPER' integer e,f,pf real x0(3) character*3 cb_surf real n1,n2,n3 real dg(3,2) real dgtq(3,4) real xm0 (lx1,ly1,lz1,lelt) real ym0 (lx1,ly1,lz1,lelt) real zm0 (lx1,ly1,lz1,lelt) real sij (lx1,ly1,lz1,3*ldim-3,lelv) real pm1 (lx1,ly1,lz1,lelv) real visc(lx1,ly1,lz1,lelv) n=nx1*ny1*nz1*nelv call rzero(dgtq,12) nface = 2 * ndim cb_surf = 'W ' do e = 1,nelv flag = 1 do f = 1,nface if(cbc(f,e,1).eq.cb_surf.and.x.gt.-25E-02 .and. x.lt.125E-02)then flag = 0 ! Wall Element pf = eface1(f) ! convert from preproc. notation js1 = skpdat(1,pf) jf1 = skpdat(2,pf) jskip1 = skpdat(3,pf) js2 = skpdat(4,pf) jf2 = skpdat(5,pf) jskip2 = skpdat(6,pf) if (if3d.or.ifaxis) then i = 0 a = 0 do j2=js2,jf2,jskip2 do j1=js1,jf1,jskip1 i = i+1 n1 = unx(i,1,f,e)*area(i,1,f,e) n2 = uny(i,1,f,e)*area(i,1,f,e) n3 = unz(i,1,f,e)*area(i,1,f,e) a = a + area(i,1,f,e) c v = visc(j1,j2,1,e) c s11 = sij(j1,j2,1,1,e) s21 = sij(j1,j2,1,4,e) s31 = sij(j1,j2,1,6,e) c s12 = sij(j1,j2,1,4,e) s22 = sij(j1,j2,1,2,e) s32 = sij(j1,j2,1,5,e) c s13 = sij(j1,j2,1,6,e) s23 = sij(j1,j2,1,5,e) s33 = sij(j1,j2,1,3,e) c dg(1,1) = pm1(j1,j2,1,e)*n1 ! pressure drag dg(2,1) = pm1(j1,j2,1,e)*n2 dg(3,1) = pm1(j1,j2,1,e)*n3 c dg(1,2) = -v*(s11*n1 + s12*n2 + s13*n3) ! viscous drag dg(2,2) = -v*(s21*n1 + s22*n2 + s23*n3) dg(3,2) = -v*(s31*n1 + s32*n2 + s33*n3) c r1 = xm0(j1,j2,1,e) r2 = ym0(j1,j2,1,e) r3 = zm0(j1,j2,1,e) c do l=1,2 do k=1,3 dgtq(k,l) = dgtq(k,l) + dg(k,l) enddo enddo c dgtq(1,3) = dgtq(1,3) + (r2*dg(3,1)-r3*dg(2,1)) ! pressure dgtq(2,3) = dgtq(2,3) + (r3*dg(1,1)-r1*dg(3,1)) ! torque dgtq(3,3) = dgtq(3,3) + (r1*dg(2,1)-r2*dg(1,1)) c dgtq(1,4) = dgtq(1,4) + (r2*dg(3,2)-r3*dg(2,2)) ! viscous dgtq(2,4) = dgtq(2,4) + (r3*dg(1,2)-r1*dg(3,2)) ! torque dgtq(3,4) = dgtq(3,4) + (r1*dg(2,2)-r2*dg(1,2)) enddo enddo endif endif enddo enddo return end Thanks and Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 14 12:35:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 12:35:00 -0500 Subject: [Nek5000-users] Split/Stress Formulations Message-ID: Hello, I am quite interested in knowing in what instances one would employ Stress / Non-stress / Split formulation. I noticed in turbchannel.usr that one must use the stress formulation if PN-PN-2 basis is chosen. Should a different formulation be used for say PN-PN basis or are they conditions under which one would judiciously choose these formulations ? Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 14 12:51:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 12:51:58 -0500 (CDT) Subject: [Nek5000-users] Split/Stress Formulations In-Reply-To: References: Message-ID: Shriram, In general, if you have variable viscosity or free surface you should likely use the stress fomulation, unless the extra terms in the stress tensor are treated explicitly in the .usr file. For marginally resolved turbulent flows we've found the PnPn formulation to be more accurate, in part because of the more accurate pressure treatment. hth, Paul On Wed, 14 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am quite interested in knowing in what instances one would employ Stress / > Non-stress / Split formulation. > I noticed in turbchannel.usr that one must use the stress formulation if > PN-PN-2 basis is chosen. > Should a different formulation be used for say PN-PN basis or are they > conditions under which one would > judiciously choose these formulations ? > > Regards > Shriram > From nek5000-users at lists.mcs.anl.gov Wed Apr 14 12:53:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 14 Apr 2010 12:53:20 -0500 (CDT) Subject: [Nek5000-users] Calculating wall shear stress and dimensionless wall distances In-Reply-To: References: Message-ID: For the postx approach, you don't need points associated w/ the mesh, just points that are on the surface of your geometry. (Sorry for the short response, but I have to leave the office right now...) Paul On Wed, 14 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul, > > Thank you for the reply. I tried to implement the code in the usrchk > subroutine but found that the values of dgtq and dg are zeros. I tried to > identify the wall boundary conditions and found the corresponding the > elements , faces and used the code snippet. I am sure I am missing something > here.. Any thoughts ? > > However the way you said with the postx works. It did give me a profile.out > and I am currently working on a way to post-process it. I have close to 25k > elements and probably a few hundred elements near the blade and I am not > quite sure how to grab the coordinates to enter into the prof.in file. > Ideally I would like to get the yplus/z plus for the first couple of > elements or so. I tried the same way of grabbing the elements and faces near > the area of interest, but I am clueless as to how I access the co-ordinate > data of those elements. > > I had another question regarding span-wise averaging of shear stress, Once I > calculate the shear stress using the above routine, could I use the > z_average() routine in navier5.f to do the span-wise averaging ? I was > looking at the turbchannel.usr where the wall shear stress and averaging > process is done but did not make a huge progress.. > > > subroutine usrchk > include 'SIZE' > include 'TOTAL' > include 'ZPER' > > integer e,f,pf > real x0(3) > character*3 cb_surf > real n1,n2,n3 > real dg(3,2) > real dgtq(3,4) > real xm0 (lx1,ly1,lz1,lelt) > real ym0 (lx1,ly1,lz1,lelt) > real zm0 (lx1,ly1,lz1,lelt) > real sij (lx1,ly1,lz1,3*ldim-3,lelv) > real pm1 (lx1,ly1,lz1,lelv) > real visc(lx1,ly1,lz1,lelv) > > n=nx1*ny1*nz1*nelv > > call rzero(dgtq,12) > > nface = 2 * ndim > cb_surf = 'W ' > do e = 1,nelv > flag = 1 > do f = 1,nface > if(cbc(f,e,1).eq.cb_surf.and.x.gt.-25E-02 .and. x.lt.125E-02)then > flag = 0 ! Wall Element > pf = eface1(f) ! convert from preproc. notation > > js1 = skpdat(1,pf) > jf1 = skpdat(2,pf) > jskip1 = skpdat(3,pf) > js2 = skpdat(4,pf) > jf2 = skpdat(5,pf) > jskip2 = skpdat(6,pf) > > if (if3d.or.ifaxis) then > i = 0 > a = 0 > do j2=js2,jf2,jskip2 > do j1=js1,jf1,jskip1 > i = i+1 > n1 = unx(i,1,f,e)*area(i,1,f,e) > n2 = uny(i,1,f,e)*area(i,1,f,e) > n3 = unz(i,1,f,e)*area(i,1,f,e) > a = a + area(i,1,f,e) > c > v = visc(j1,j2,1,e) > c > s11 = sij(j1,j2,1,1,e) > s21 = sij(j1,j2,1,4,e) > s31 = sij(j1,j2,1,6,e) > c > s12 = sij(j1,j2,1,4,e) > s22 = sij(j1,j2,1,2,e) > s32 = sij(j1,j2,1,5,e) > c > s13 = sij(j1,j2,1,6,e) > s23 = sij(j1,j2,1,5,e) > s33 = sij(j1,j2,1,3,e) > c > dg(1,1) = pm1(j1,j2,1,e)*n1 ! pressure drag > dg(2,1) = pm1(j1,j2,1,e)*n2 > dg(3,1) = pm1(j1,j2,1,e)*n3 > c > dg(1,2) = -v*(s11*n1 + s12*n2 + s13*n3) ! viscous drag > dg(2,2) = -v*(s21*n1 + s22*n2 + s23*n3) > dg(3,2) = -v*(s31*n1 + s32*n2 + s33*n3) > c > r1 = xm0(j1,j2,1,e) > r2 = ym0(j1,j2,1,e) > r3 = zm0(j1,j2,1,e) > c > do l=1,2 > do k=1,3 > dgtq(k,l) = dgtq(k,l) + dg(k,l) > enddo > enddo > c > dgtq(1,3) = dgtq(1,3) + (r2*dg(3,1)-r3*dg(2,1)) ! pressure > dgtq(2,3) = dgtq(2,3) + (r3*dg(1,1)-r1*dg(3,1)) ! torque > dgtq(3,3) = dgtq(3,3) + (r1*dg(2,1)-r2*dg(1,1)) > c > dgtq(1,4) = dgtq(1,4) + (r2*dg(3,2)-r3*dg(2,2)) ! viscous > dgtq(2,4) = dgtq(2,4) + (r3*dg(1,2)-r1*dg(3,2)) ! torque > dgtq(3,4) = dgtq(3,4) + (r1*dg(2,2)-r2*dg(1,2)) > enddo > enddo > endif > endif > enddo > enddo > > return > end > > > > > Thanks and Regards > Shriram > From nek5000-users at lists.mcs.anl.gov Thu Apr 15 05:58:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Apr 2010 12:58:54 +0200 Subject: [Nek5000-users] CFL Message-ID: <1271329134.518.42.camel@localhost.localdomain> Hello all, Is it possible to have the maximum CFL # (even better the maximum in each direction x,y,z) written out to the screen? I see the line in "drive2.f": WRITE (6,100) ISTEP,TIME,DT,COURNO/10,TTIME,TTIME_STP It seems this is the maximum CFL #, but I don't understand the "/10". Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Apr 15 06:21:43 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Apr 2010 13:21:43 +0200 Subject: [Nek5000-users] CFL In-Reply-To: <1271329134.518.42.camel@localhost.localdomain> References: <1271329134.518.42.camel@localhost.localdomain> Message-ID: <6A078F25-8C7F-42B9-BB74-156940C81CC2@lav.mavt.ethz.ch> We print out the maximum CFL number in the domain. See C in this example: Step 3, t= 1.5000000E-02, DT= 5.0000000E-03, C= 0.128 1.9712E+00 9.8788E-01 The write statement is correct. Here, we're using a mixed '1pE/F' format and the 'F' formatted C gets multiplied by 10. Not many people are aware of that but try it out. hth, Stefan On Apr 15, 2010, at 12:58 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > Is it possible to have the maximum CFL # (even better the maximum in > each direction x,y,z) written out to the screen? I see the line in > "drive2.f": > WRITE (6,100) ISTEP,TIME,DT,COURNO/10,TTIME,TTIME_STP > > It seems this is the maximum CFL #, but I don't understand the "/10". > > Cheers, > Frank > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 15 06:20:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Apr 2010 06:20:59 -0500 (CDT) Subject: [Nek5000-users] CFL In-Reply-To: <1271329134.518.42.camel@localhost.localdomain> References: <1271329134.518.42.camel@localhost.localdomain> Message-ID: Hi Frank, Presently, the max cfl is written -- the /10 is because of the p-format in the following format stmt, e.g., 1pe12.4 is like e-format, 0.1234e07, save that it shifts the significant digits to the left to give 1.2345e06, which provides one more digit in the same space. (A trick I learned from the linpack/lapack source.) Oddly, the "1p" has the effect of shifting all reals that appear to the right of the first instance of the p-format to the left, even if they are printed in std. "f-format". The "/10" unwinds this shift. If you want the max in each direction you could make a copy of the routine that computes it, rename it, instrument it, add it to your .usr file and call it from userchk --- this way you'll continue to be repo- compatible but have full access to the information you desire. I usually call it blahx if the original was blah. Paul On Thu, 15 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, Is it possible to have the maximum CFL # (even better the maximum in each direction x,y,z) written out to the screen? I see the line in "drive2.f": WRITE (6,100) ISTEP,TIME,DT,COURNO/10,TTIME,TTIME_STP It seems this is the maximum CFL #, but I don't understand the "/10". Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 15 14:41:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Apr 2010 21:41:06 +0200 Subject: [Nek5000-users] linking Message-ID: <1271360467.4107.27.camel@localhost.localdomain> Hello all, I am coming across a linking problem. When using the below linking fails. parameter (lx1=8*5... parameter (lxd=12*5... But this is OK: parameter (lx1=8*4... parameter (lxd=12*4... The error message is: sunf95 -c -O2 -r8const -xtypemap=real:64 -fpp -DLONGINT8 -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim4 /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim4/openboat.f -o openboat.o sunf95 -o nek5000 openboat.o drive.o drive1.o drive2.o plan4.o bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o mpi_dummy.o jl2_gs.o jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o bdry.o: In function `bcneutr_': bdry.f:(.text+0x6885): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o bdry.f:(.text+0x68c1): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o bdry.o: In function `trstax_': bdry.f:(.text+0x759c): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o bdry.f:(.text+0x75a3): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o bdry.f:(.text+0x75cd): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o bdry.f:(.text+0x75de): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o bdry.f:(.text+0x75f6): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o bdry.f:(.text+0x7607): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o bdry.f:(.text+0x7630): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o bdry.f:(.text+0x7641): relocation truncated to fit: R_X86_64_PC32 against symbol `ctmp0_' defined in COMMON section in navier5.o -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Apr 15 14:58:56 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Apr 2010 21:58:56 +0200 Subject: [Nek5000-users] linking In-Reply-To: <1271360467.4107.27.camel@localhost.localdomain> References: <1271360467.4107.27.camel@localhost.localdomain> Message-ID: <754EDCBF-0C5A-44D8-98CA-A7BEA43BD315@lav.mavt.ethz.ch> Frank, using the std-memory model the total size of all static data items is limited by the compiler to 2GB. Try to lower lelt (you may have to use more processors) for a given lx1/lxd to lower the memory footprint. Stefan On Apr 15, 2010, at 9:41 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I am coming across a linking problem. When using the below linking > fails. > parameter (lx1=8*5... > parameter (lxd=12*5... > > But this is OK: > parameter (lx1=8*4... > parameter (lxd=12*4... > > The error message is: > > sunf95 -c -O2 -r8const -xtypemap=real:64 -fpp -DLONGINT8 > -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek > -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim4 /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim4/openboat.f -o openboat.o > sunf95 -o nek5000 openboat.o drive.o drive1.o drive2.o plan4.o bdry.o > coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o gauss.o > genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o prepost.o > speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o > mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o > subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o > navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o > byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o > makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o mpi_dummy.o > jl2_gs.o jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o > jl2_gs_local.o jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o > jl2_fcrystal.o jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o > jl_errmem.o jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o > jl_findpt.o jl_poly.o jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o > bdry.o: In function `bcneutr_': > bdry.f:(.text+0x6885): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > bdry.f:(.text+0x68c1): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > bdry.o: In function `trstax_': > bdry.f:(.text+0x759c): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > bdry.f:(.text+0x75a3): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > bdry.f:(.text+0x75cd): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > bdry.f:(.text+0x75de): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > bdry.f:(.text+0x75f6): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > bdry.f:(.text+0x7607): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > bdry.f:(.text+0x7630): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > bdry.f:(.text+0x7641): relocation truncated to fit: R_X86_64_PC32 > against symbol `ctmp0_' defined in COMMON section in navier5.o > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 15 15:01:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Apr 2010 22:01:16 +0200 Subject: [Nek5000-users] ifield In-Reply-To: <6A078F25-8C7F-42B9-BB74-156940C81CC2@lav.mavt.ethz.ch> References: <1271329134.518.42.camel@localhost.localdomain> <6A078F25-8C7F-42B9-BB74-156940C81CC2@lav.mavt.ethz.ch> Message-ID: <1271361677.4107.33.camel@localhost.localdomain> Hello all, I am looking for how to assure that one and only one fluid is used. For instance, in the following snippet, "ifield" should not be greater than 1. I guess am not sure what "ifield" means exactly. if (ifield.eq.1) then ! fluid/gas utrans=param(1) ! density of liquid udiff =param(2) ! dynamic viscosity of liquid else ! Thermal properties utrans=.1*param(7) ! rhocp, liquid udiff =.1*param(8) ! conductivity, liquid endif Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Apr 15 15:40:13 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 15 Apr 2010 15:40:13 -0500 (CDT) Subject: [Nek5000-users] ifield In-Reply-To: <1271361677.4107.33.camel@localhost.localdomain> References: <1271329134.518.42.camel@localhost.localdomain> <6A078F25-8C7F-42B9-BB74-156940C81CC2@lav.mavt.ethz.ch> <1271361677.4107.33.camel@localhost.localdomain> Message-ID: Frank, ifield=1 --> fluid 2 --> thermal (temperature) 3 --> passive scalar 1 4 --> ps 2 , etc. There is another flag "group" which I no longer support which one can use to discriminate different fluid regions w/ different propoerties. I prefer user-defined discriminators, typically based on geometry. Your usage below would work fine for a single liquid phase. Paul On Thu, 15 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, I am looking for how to assure that one and only one fluid is used. For instance, in the following snippet, "ifield" should not be greater than 1. I guess am not sure what "ifield" means exactly. if (ifield.eq.1) then ! fluid/gas utrans=param(1) ! density of liquid udiff =param(2) ! dynamic viscosity of liquid else ! Thermal properties utrans=.1*param(7) ! rhocp, liquid udiff =.1*param(8) ! conductivity, liquid endif Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Sun Apr 18 23:24:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 18 Apr 2010 23:24:53 -0500 Subject: [Nek5000-users] Data Structure Message-ID: Hello, I am trying to understand the structure of the arrays that store velocities and co-ordinates in nek that is available under several subroutines like uskchk,usrdat2,usrdat etc. Based on my understanding, I found that the velocities, say vx has the form vx(lx1,ly1,lz1,e) but I found that there are many arrays that address the co-ordinates namely xm0,xm1,xc etc though I am not sure what it denotes. Can all these be accessed from any subroutine in the usr file ? I have attached herewith a picture where I have mentioned how I thought the data structure might be. But, I would really like to know how one would access the co-ordinates of say ,a particular element and what xm0,xm1,xc denote for. Please correct me if I am wrong about the data structure. Thanks. Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Array_Struct.pdf Type: application/pdf Size: 9401 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 19 03:46:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 10:46:44 +0200 Subject: [Nek5000-users] Data Structure In-Reply-To: References: Message-ID: <80C05291-DABB-4D08-9DB3-2D3758E67E5F@lav.mavt.ethz.ch> Hi Shriram, {XM1,YM1,ZM1} stores the GLL mesh for the velocity and {XM2,YM2,ZM2} stores GL or GLL points for the pressure (defined in the GEOM CB). The mesh points are stored in a lexicographical order. {XC,YC,ZC} stores the element vertices (defined in the INPUT CB). Note: we read the vertices into NEK using a preprocessor notation. However internally we use a different symmetric notation. For more details check the header of genxyzl(). In general you have access to all the arrays you like as long as you have a proper include statement for the CB in question. Is there any specific reason why you want to have access to a particular point in the mesh? Stefan On Apr 19, 2010, at 6:24 AM, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am trying to understand the structure of the arrays that store velocities and co-ordinates in nek that is available under several subroutines like uskchk,usrdat2,usrdat etc. > Based on my understanding, I found that the velocities, say vx has the form vx(lx1,ly1,lz1,e) but I found that there are many arrays that address the co-ordinates namely xm0,xm1,xc etc though I am not sure what it denotes. Can all these be accessed from any subroutine in the usr file ? I have attached herewith a picture where I have mentioned how I thought the data structure might be. But, I would really like to know how one would access the co-ordinates of say ,a particular element and what xm0,xm1,xc denote for. Please correct me if I am wrong about the data structure. Thanks. > > Regards > Shriram Jagannathan > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 05:37:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 05:37:49 -0500 (CDT) Subject: [Nek5000-users] Data Structure In-Reply-To: References: Message-ID: Hi Shriram, Your interpretation of the layout is correct. For the most part, the geometry arrays of interest are xm1(i,j,k,e) ym1(i,j,k,e) zm1(i,j,k,e) which give the (x,y,z) coordinates for every element e=1,...,nelt on processor p, p=1,...,P. (Note that there is no index to reflect "p" --- that index is defined implicitly by the distributed memory model; each processor has it's own unique set of data: given i,j,k,e,p, one can find the associated (x,y,z) point. The inverse problem of finding i,j,k,e,p for a given (x,y,z) value is much more difficult (and expensive), but we have routines to handle this.) Your picture is essentially correct, save that it is not requisite that the element be oriented with the x-y axis. It could just as well have been rotated by 45 or 90 degrees, say. We retain separate arrays for the geometry in order to support curvilinear elements having deformation and rotation that can accommodate complex shapes. (A detailed description can be found in Deville, Fischer, Mund, "High-Order Methods for Fluid Flow", which might be in your library. I'm hoping to get additional description in a forthcoming reference manual.) Paul On Sun, 18 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am trying to understand the structure of the arrays that store velocities > and co-ordinates in nek that is available under several subroutines like > uskchk,usrdat2,usrdat etc. > Based on my understanding, I found that the velocities, say vx has the form > vx(lx1,ly1,lz1,e) but I found that there are many arrays that address the > co-ordinates namely xm0,xm1,xc etc though I am not sure what it denotes. Can > all these be accessed from any subroutine in the usr file ? I have attached > herewith a picture where I have mentioned how I thought the data structure > might be. But, I would really like to know how one would access the > co-ordinates of say ,a particular element and what xm0,xm1,xc denote for. > Please correct me if I am wrong about the data structure. Thanks. > > Regards > Shriram Jagannathan > From nek5000-users at lists.mcs.anl.gov Mon Apr 19 07:02:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 07:02:53 -0500 Subject: [Nek5000-users] Simulation blows up after running for approx. 53500 time steps!! Message-ID: <8e6554296dc3f4318f8216c7a8f9bb6a.squirrel@webmail.uic.edu> Hello, I am running a DNS simulation of backward facing simulation (BFS) at Re=3000. The Reynolds # is based on step height (h=1) & free stream velocity (ux = 1.0). The BFS geometry has 5184 elements and lx1=ly1=lz1=8. I have attached the *.rea and *.usr files. I am running the case on 512 processors. The case blows up after approx. 53500 time steps with dt=5e-4. After analyzing the case in VIsit, it looks as if the simulation blows up as the vortex reaches the outflow boundary for the first time. I think, the normal outflow boundary condition is not sufficient. I have attached a shortened version of the logfile for reference. The movie for the simulation can be seen at the following link. http://www2.uic.edu/~hkanch1/movie.mpeg Any suggestions on how to fix the problem would be helpful. Thanks for all the help. Harish. -------------- next part -------------- A non-text attachment was scrubbed... Name: bfs3d.usr Type: application/octet-stream Size: 4477 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logfile1 Type: application/octet-stream Size: 318095 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 19 07:14:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 14:14:15 +0200 Subject: [Nek5000-users] Simulation blows up after running for approx. 53500 time steps!! In-Reply-To: <8e6554296dc3f4318f8216c7a8f9bb6a.squirrel@webmail.uic.edu> References: <8e6554296dc3f4318f8216c7a8f9bb6a.squirrel@webmail.uic.edu> Message-ID: <9A2ECFC8-0D6C-4932-9B84-474130792DDE@lav.mavt.ethz.ch> Try to add some divergence to the outflow boundary to accelerate the flow. You'll find an example in the turbJet example (see accl_outflow). This will work well if you're right and the problem is related to a significant backflow at the outflow boundary. Some solver performance suggestions: - lower your pressure tolerance (e.g 1e-5 is typically strict enough) - your timestep seems to be quite low (check the CFL-number). If the field is fully turbulent and you use IFCHAR=.false. you're stable up to CFL ~ 0.5. If you use the characteristics scheme try to use a dt such that CFL = 2 (make sure you set COURANT in the .rea file correct). Stefan On Apr 19, 2010, at 2:02 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am running a DNS simulation of backward facing simulation (BFS) at > Re=3000. The Reynolds # is based on step height (h=1) & free stream > velocity (ux = 1.0). The BFS geometry has 5184 elements and lx1=ly1=lz1=8. > I have attached the *.rea and *.usr files. I am running the case on 512 > processors. > > The case blows up after approx. 53500 time steps with dt=5e-4. After > analyzing the case in VIsit, it looks as if the simulation blows up as the > vortex reaches the outflow boundary for the first time. I think, the > normal outflow boundary condition is not sufficient. I have attached a > shortened version of the logfile for reference. > > The movie for the simulation can be seen at the following link. > > http://www2.uic.edu/~hkanch1/movie.mpeg > > Any suggestions on how to fix the problem would be helpful. > > Thanks for all the help. > > Harish._______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 07:27:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 07:27:54 -0500 (CDT) Subject: [Nek5000-users] BFS turbulent outflow condition Message-ID: Hi Harish, (This is a re-send of my Friday response, which looks like it may not have gone through...) There is a std cure for this problem, which is to force the velocity characteristics at the outflow boundary to all be outgoing. You can do this by specifying div U > 0 in the last layer of elements --- by filling up the usrdiv() array. See the .usr files in the /peris and /turbJet examples. (From the /examples directory, grep div */*.usr will point the way.) Paul On Fri, 16 Apr 2010, nek5000-users-owner at lists.mcs.anl.gov wrote: > As list administrator, your authorization is requested for the > following mailing list posting: > > List: Nek5000-users at lists.mcs.anl.gov > From: hkanch1 at uic.edu > Subject: Simulation blows up after running for approx. 53500 time steps!! > Reason: Message body is too big: 568880 bytes with a limit of 512 KB > > At your convenience, visit: > > https://lists.mcs.anl.gov/mailman/admindb/nek5000-users > > to approve or deny the request. > From nek5000-users at lists.mcs.anl.gov Mon Apr 19 07:30:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 07:30:53 -0500 (CDT) Subject: [Nek5000-users] Simulation blows up after running for approx. 53500 time steps!! In-Reply-To: <9A2ECFC8-0D6C-4932-9B84-474130792DDE@lav.mavt.ethz.ch> References: <8e6554296dc3f4318f8216c7a8f9bb6a.squirrel@webmail.uic.edu> <9A2ECFC8-0D6C-4932-9B84-474130792DDE@lav.mavt.ethz.ch> Message-ID: Thanks Stefan I will try these suggestions and check the turbJet example. Harish. On Mon, 19 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > Try to add some divergence to the outflow boundary to accelerate the flow. You'll find an example in the turbJet example (see accl_outflow). This will work well if you're right and the problem is related to a significant backflow at the outflow boundary. > > Some solver performance suggestions: > > - lower your pressure tolerance (e.g 1e-5 is typically strict enough) > - your timestep seems to be quite low (check the CFL-number). If the field is fully turbulent and you use IFCHAR=.false. you're stable up to CFL ~ 0.5. If you use the characteristics scheme try to use a dt such that CFL = 2 (make sure you set COURANT in the .rea file correct). > > > Stefan > > > On Apr 19, 2010, at 2:02 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello, > > > > I am running a DNS simulation of backward facing simulation (BFS) at > > Re=3000. The Reynolds # is based on step height (h=1) & free stream > > velocity (ux = 1.0). The BFS geometry has 5184 elements and lx1=ly1=lz1=8. > > I have attached the *.rea and *.usr files. I am running the case on 512 > > processors. > > > > The case blows up after approx. 53500 time steps with dt=5e-4. After > > analyzing the case in VIsit, it looks as if the simulation blows up as the > > vortex reaches the outflow boundary for the first time. I think, the > > normal outflow boundary condition is not sufficient. I have attached a > > shortened version of the logfile for reference. > > > > The movie for the simulation can be seen at the following link. > > > > http://www2.uic.edu/~hkanch1/movie.mpeg > > > > Any suggestions on how to fix the problem would be helpful. > > > > Thanks for all the help. > > > > Harish._______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Apr 19 07:33:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 07:33:09 -0500 (CDT) Subject: [Nek5000-users] BFS turbulent outflow condition In-Reply-To: References: Message-ID: Hi Paul, Thanks for the response. I did not get your response from Friday, its very strange. I will take a look at .usr file in the /peris & /turbJet examples. Harish On Mon, 19 Apr 2010 nek5000-users at lists.mcs.anl.gov wrote: > > > > Hi Harish, > > (This is a re-send of my Friday response, which looks like > it may not have gone through...) > > There is a std cure for this problem, which is to force > the velocity characteristics at the outflow boundary to > all be outgoing. You can do this by specifying div U > 0 > in the last layer of elements --- by filling up the > usrdiv() array. > > See the .usr files in the /peris and /turbJet examples. > > (From the /examples directory, grep div */*.usr will point > the way.) > > Paul > > > > On Fri, 16 Apr 2010, nek5000-users-owner at lists.mcs.anl.gov wrote: > > > As list administrator, your authorization is requested for the > > following mailing list posting: > > > > List: Nek5000-users at lists.mcs.anl.gov > > From: hkanch1 at uic.edu > > Subject: Simulation blows up after running for approx. 53500 time steps!! > > Reason: Message body is too big: 568880 bytes with a limit of 512 KB > > > > At your convenience, visit: > > > > https://lists.mcs.anl.gov/mailman/admindb/nek5000-users > > > > to approve or deny the request. > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Apr 19 10:30:42 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 17:30:42 +0200 Subject: [Nek5000-users] *.fld files to ... Message-ID: <1271691042.5273.37.camel@localhost.localdomain> Hello all, Does anyone know of a way to translate *.fld files to a different format (perhaps such as HDF, CGNS, Plot3D etc.)? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 19 10:34:17 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 17:34:17 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <1271691042.5273.37.camel@localhost.localdomain> References: <1271691042.5273.37.camel@localhost.localdomain> Message-ID: Frank, read your data into VisIt and use the export option. I don't recall exactly what output formats they support but there are quite a few. Stefan On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > Does anyone know of a way to translate *.fld files to a different format > (perhaps such as HDF, CGNS, Plot3D etc.)? > > Cheers, > Frank > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 10:57:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 17:57:59 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: References: <1271691042.5273.37.camel@localhost.localdomain> Message-ID: <1271692679.5273.44.camel@localhost.localdomain> Hi Stefan, Thanks. I had tried that. This translator appears to be a fairly rough attempt to output data in Tecplot's format. It at times writes out files that Tecplot cannot read. In addition, if dealing with temporal data, there appears to be no way to write out the data at each time step to a single Tecplot file. Therefore, one would need to do this (exporting through the menus) for every file at every time step. Cheers, Frank On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > read your data into VisIt and use the export option. > I don't recall exactly what output formats they support but there are quite a few. > > Stefan > > > On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > > > Does anyone know of a way to translate *.fld files to a different format > > (perhaps such as HDF, CGNS, Plot3D etc.)? > > > > Cheers, > > Frank > > > > > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:02:40 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:02:40 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <1271692679.5273.44.camel@localhost.localdomain> References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> Message-ID: <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). If you know the data layout of NEK it's quite easy write your own convert. We did that for TecPlot some time ago. Stefan On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > Thanks. I had tried that. This translator appears to be a fairly rough > attempt to output data in Tecplot's format. It at times writes out > files that Tecplot cannot read. In addition, if dealing with temporal > data, there appears to be no way to write out the data at each time step > to a single Tecplot file. Therefore, one would need to do this > (exporting through the menus) for every file at every time step. > > Cheers, > Frank > > > On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Frank, >> >> read your data into VisIt and use the export option. >> I don't recall exactly what output formats they support but there are quite a few. >> >> Stefan >> >> >> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >>> >>> Does anyone know of a way to translate *.fld files to a different format >>> (perhaps such as HDF, CGNS, Plot3D etc.)? >>> >>> Cheers, >>> Frank >>> >>> >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:03:39 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 09:03:39 -0700 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <1271692679.5273.44.camel@localhost.localdomain> References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> Message-ID: Hi Frank, It is possible to automate the Exports through VisIt. I can help you with a script if you'd like. That said, as Stefan points out, the TecPlot writer is limited. Best, Hank On Mon, Apr 19, 2010 at 8:57 AM, wrote: > Hi Stefan, > > Thanks. I had tried that. This translator appears to be a fairly rough > attempt to output data in Tecplot's format. It at times writes out > files that Tecplot cannot read. In addition, if dealing with temporal > data, there appears to be no way to write out the data at each time step > to a single Tecplot file. Therefore, one would need to do this > (exporting through the menus) for every file at every time step. > > Cheers, > Frank > > > On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Frank, >> >> read your data into VisIt and use the export option. >> I don't recall exactly what output formats they support but there are quite a few. >> >> Stefan >> >> >> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> > Hello all, >> > >> > Does anyone know of a way to translate *.fld files to a different format >> > (perhaps such as HDF, CGNS, Plot3D etc.)? >> > >> > Cheers, >> > Frank >> > >> > >> > -- >> > Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> > Technische Universit?t Wien (Technical University of Vienna) >> > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> > Mechanics and Heat Transfer) >> > Resselgasse 3 >> > 1040 Wien >> > Tel: +4315880132232 >> > Fax: +4315880132299 >> > Cell:+436765203470 >> > fmuldoo (skype) >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> > >> > _______________________________________________ >> > Nek5000-users mailing list >> > Nek5000-users at lists.mcs.anl.gov >> > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:05:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 11:05:59 -0500 Subject: [Nek5000-users] Nek5000-users Digest, Vol 14, Issue 29 In-Reply-To: References: Message-ID: Stefan, Many thanks for your reply. I am trying to find the velocity gradients near the wall. I identified the walls of interest and have collected the element number and faces of each of them. And then approximately I try to compute du/dy, so I tried to access the velocity at the GLL points and the co-ordinates. I just found that nek has a routine comp_gije(), which I believe is to compute the gradients. I now plan to use that to compute the gradients near the wall. In a earlier mail, Paul had mentioned the different ways of computing the gradients and I am looking at few of them. Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:06:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:06:58 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> Message-ID: Hi Hank, welcome to the NEK5000 community :) It's good to have a real viz-expert onboard! Cheers, Stefan On Apr 19, 2010, at 6:03 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > It is possible to automate the Exports through VisIt. I can help you > with a script if you'd like. That said, as Stefan points out, the > TecPlot writer is limited. > > Best, > Hank > > On Mon, Apr 19, 2010 at 8:57 AM, wrote: >> Hi Stefan, >> >> Thanks. I had tried that. This translator appears to be a fairly rough >> attempt to output data in Tecplot's format. It at times writes out >> files that Tecplot cannot read. In addition, if dealing with temporal >> data, there appears to be no way to write out the data at each time step >> to a single Tecplot file. Therefore, one would need to do this >> (exporting through the menus) for every file at every time step. >> >> Cheers, >> Frank >> >> >> On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov >> wrote: >>> Frank, >>> >>> read your data into VisIt and use the export option. >>> I don't recall exactly what output formats they support but there are quite a few. >>> >>> Stefan >>> >>> >>> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello all, >>>> >>>> Does anyone know of a way to translate *.fld files to a different format >>>> (perhaps such as HDF, CGNS, Plot3D etc.)? >>>> >>>> Cheers, >>>> Frank >>>> >>>> >>>> -- >>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>> Technische Universit?t Wien (Technical University of Vienna) >>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>> Mechanics and Heat Transfer) >>>> Resselgasse 3 >>>> 1040 Wien >>>> Tel: +4315880132232 >>>> Fax: +4315880132299 >>>> Cell:+436765203470 >>>> fmuldoo (skype) >>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 >> Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:11:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:11:09 +0200 Subject: [Nek5000-users] Nek5000-users Digest, Vol 14, Issue 29 In-Reply-To: References: Message-ID: <7FA8A23B-0927-4330-B6F2-AC512E63B516@lav.mavt.ethz.ch> Assuming you know the locations where you want to compute the stress tensor you can use our interpolation tool in NEK. You just have to provide a list of points and field and you'll get the interpolated values back. This works in parallel and you don't need to worry about where these points are. Stefan On Apr 19, 2010, at 6:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > Stefan, > > Many thanks for your reply. I am trying to find the velocity gradients near the wall. I identified the walls of interest and have collected the element number and faces of each of them. And then approximately I try to compute du/dy, so I tried to access the velocity at the GLL points and the co-ordinates. > > I just found that nek has a routine comp_gije(), which I believe is to compute the gradients. I now plan to use that to compute the gradients near the wall. In a earlier mail, Paul had mentioned the different ways of computing the gradients and I am looking at few of them. > > Regards > Shriram Jagannathan > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:12:37 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 11:12:37 -0500 Subject: [Nek5000-users] Nek5000-users Digest, Vol 14, Issue 29 In-Reply-To: References: Message-ID: Paul, Thank you. I have referred to the book for a project and have a very basic idea of spectral element method. Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:19:00 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:19:00 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> Message-ID: <1271693940.9761.2.camel@localhost.localdomain> Hello Stefan, Actually I would like to do that. I am quite familiar with I/O and Tecplot and could make a writer that outputs their binary format files. This could be done two ways, outputting directly from NEK to Tecplot format files (and therefore not using the *.fld files for I/O) or something that takes the *.fld files and creates Tecplot format files. I tend to think the second is the best method as the issue of parallel I/O is sidestepped. What is your opinion on this? Cheers, Frank On Mon, 2010-04-19 at 18:02 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). > If you know the data layout of NEK it's quite easy write your own convert. > We did that for TecPlot some time ago. > > Stefan > > > On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Stefan, > > > > Thanks. I had tried that. This translator appears to be a fairly rough > > attempt to output data in Tecplot's format. It at times writes out > > files that Tecplot cannot read. In addition, if dealing with temporal > > data, there appears to be no way to write out the data at each time step > > to a single Tecplot file. Therefore, one would need to do this > > (exporting through the menus) for every file at every time step. > > > > Cheers, > > Frank > > > > > > On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Frank, > >> > >> read your data into VisIt and use the export option. > >> I don't recall exactly what output formats they support but there are quite a few. > >> > >> Stefan > >> > >> > >> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hello all, > >>> > >>> Does anyone know of a way to translate *.fld files to a different format > >>> (perhaps such as HDF, CGNS, Plot3D etc.)? > >>> > >>> Cheers, > >>> Frank > >>> > >>> > >>> -- > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>> Technische Universit?t Wien (Technical University of Vienna) > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>> Mechanics and Heat Transfer) > >>> Resselgasse 3 > >>> 1040 Wien > >>> Tel: +4315880132232 > >>> Fax: +4315880132299 > >>> Cell:+436765203470 > >>> fmuldoo (skype) > >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>> > >>> _______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:24:30 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:24:30 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <1271693940.9761.2.camel@localhost.localdomain> References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> Message-ID: Yes, I think a convert is the way to go. I will release at some point my old TecPlot convert however I need to fix a few things first. Unfortunately I am quite busy these days so it will take some time. Stefan On Apr 19, 2010, at 6:19 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Stefan, > > Actually I would like to do that. I am quite familiar with I/O and > Tecplot and could make a writer that outputs their binary format files. > This could be done two ways, outputting directly from NEK to Tecplot > format files (and therefore not using the *.fld files for I/O) or > something that takes the *.fld files and creates Tecplot format files. > I tend to think the second is the best method as the issue of parallel > I/O is sidestepped. What is your opinion on this? > > Cheers, > Frank > > > On Mon, 2010-04-19 at 18:02 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). >> If you know the data layout of NEK it's quite easy write your own convert. >> We did that for TecPlot some time ago. >> >> Stefan >> >> >> On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Stefan, >>> >>> Thanks. I had tried that. This translator appears to be a fairly rough >>> attempt to output data in Tecplot's format. It at times writes out >>> files that Tecplot cannot read. In addition, if dealing with temporal >>> data, there appears to be no way to write out the data at each time step >>> to a single Tecplot file. Therefore, one would need to do this >>> (exporting through the menus) for every file at every time step. >>> >>> Cheers, >>> Frank >>> >>> >>> On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Frank, >>>> >>>> read your data into VisIt and use the export option. >>>> I don't recall exactly what output formats they support but there are quite a few. >>>> >>>> Stefan >>>> >>>> >>>> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hello all, >>>>> >>>>> Does anyone know of a way to translate *.fld files to a different format >>>>> (perhaps such as HDF, CGNS, Plot3D etc.)? >>>>> >>>>> Cheers, >>>>> Frank >>>>> >>>>> >>>>> -- >>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>>> Technische Universit?t Wien (Technical University of Vienna) >>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>>> Mechanics and Heat Transfer) >>>>> Resselgasse 3 >>>>> 1040 Wien >>>>> Tel: +4315880132232 >>>>> Fax: +4315880132299 >>>>> Cell:+436765203470 >>>>> fmuldoo (skype) >>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:29:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:29:46 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> Message-ID: Frank, why do you want to use TecPlot? I know sometime it's just because you don't want to dig into another tool. However if there are other good reasons I am sure Hank will be quite interested to improve VisIt. Stefan On Apr 19, 2010, at 6:24 PM, nek5000-users at lists.mcs.anl.gov wrote: > Yes, I think a convert is the way to go. > I will release at some point my old TecPlot convert however I need to fix a few things first. Unfortunately I am quite busy these days so it will take some time. > > Stefan > > > On Apr 19, 2010, at 6:19 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello Stefan, >> >> Actually I would like to do that. I am quite familiar with I/O and >> Tecplot and could make a writer that outputs their binary format files. >> This could be done two ways, outputting directly from NEK to Tecplot >> format files (and therefore not using the *.fld files for I/O) or >> something that takes the *.fld files and creates Tecplot format files. >> I tend to think the second is the best method as the issue of parallel >> I/O is sidestepped. What is your opinion on this? >> >> Cheers, >> Frank >> >> >> On Mon, 2010-04-19 at 18:02 +0200, nek5000-users at lists.mcs.anl.gov >> wrote: >>> Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). >>> If you know the data layout of NEK it's quite easy write your own convert. >>> We did that for TecPlot some time ago. >>> >>> Stefan >>> >>> >>> On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi Stefan, >>>> >>>> Thanks. I had tried that. This translator appears to be a fairly rough >>>> attempt to output data in Tecplot's format. It at times writes out >>>> files that Tecplot cannot read. In addition, if dealing with temporal >>>> data, there appears to be no way to write out the data at each time step >>>> to a single Tecplot file. Therefore, one would need to do this >>>> (exporting through the menus) for every file at every time step. >>>> >>>> Cheers, >>>> Frank >>>> >>>> >>>> On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov >>>> wrote: >>>>> Frank, >>>>> >>>>> read your data into VisIt and use the export option. >>>>> I don't recall exactly what output formats they support but there are quite a few. >>>>> >>>>> Stefan >>>>> >>>>> >>>>> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> Does anyone know of a way to translate *.fld files to a different format >>>>>> (perhaps such as HDF, CGNS, Plot3D etc.)? >>>>>> >>>>>> Cheers, >>>>>> Frank >>>>>> >>>>>> >>>>>> -- >>>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>>>> Technische Universit?t Wien (Technical University of Vienna) >>>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>>>> Mechanics and Heat Transfer) >>>>>> Resselgasse 3 >>>>>> 1040 Wien >>>>>> Tel: +4315880132232 >>>>>> Fax: +4315880132299 >>>>>> Cell:+436765203470 >>>>>> fmuldoo (skype) >>>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>>>> >>>>>> _______________________________________________ >>>>>> Nek5000-users mailing list >>>>>> Nek5000-users at lists.mcs.anl.gov >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> -- >>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>> Technische Universit?t Wien (Technical University of Vienna) >>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>> Mechanics and Heat Transfer) >>>> Resselgasse 3 >>>> 1040 Wien >>>> Tel: +4315880132232 >>>> Fax: +4315880132299 >>>> Cell:+436765203470 >>>> fmuldoo (skype) >>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 >> Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:33:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:33:44 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <1271693940.9761.2.camel@localhost.localdomain> References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> Message-ID: Frank, If you're interested in my old converter we could work together to improve it. Just led me know. Stefan On Apr 19, 2010, at 6:19 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Stefan, > > Actually I would like to do that. I am quite familiar with I/O and > Tecplot and could make a writer that outputs their binary format files. > This could be done two ways, outputting directly from NEK to Tecplot > format files (and therefore not using the *.fld files for I/O) or > something that takes the *.fld files and creates Tecplot format files. > I tend to think the second is the best method as the issue of parallel > I/O is sidestepped. What is your opinion on this? > > Cheers, > Frank > > > On Mon, 2010-04-19 at 18:02 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). >> If you know the data layout of NEK it's quite easy write your own convert. >> We did that for TecPlot some time ago. >> >> Stefan >> >> >> On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Stefan, >>> >>> Thanks. I had tried that. This translator appears to be a fairly rough >>> attempt to output data in Tecplot's format. It at times writes out >>> files that Tecplot cannot read. In addition, if dealing with temporal >>> data, there appears to be no way to write out the data at each time step >>> to a single Tecplot file. Therefore, one would need to do this >>> (exporting through the menus) for every file at every time step. >>> >>> Cheers, >>> Frank >>> >>> >>> On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Frank, >>>> >>>> read your data into VisIt and use the export option. >>>> I don't recall exactly what output formats they support but there are quite a few. >>>> >>>> Stefan >>>> >>>> >>>> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hello all, >>>>> >>>>> Does anyone know of a way to translate *.fld files to a different format >>>>> (perhaps such as HDF, CGNS, Plot3D etc.)? >>>>> >>>>> Cheers, >>>>> Frank >>>>> >>>>> >>>>> -- >>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>>> Technische Universit?t Wien (Technical University of Vienna) >>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>>> Mechanics and Heat Transfer) >>>>> Resselgasse 3 >>>>> 1040 Wien >>>>> Tel: +4315880132232 >>>>> Fax: +4315880132299 >>>>> Cell:+436765203470 >>>>> fmuldoo (skype) >>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:40:10 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:40:10 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> Message-ID: <1271695210.9761.7.camel@localhost.localdomain> Hi Stefan, Yes, that is pretty much it; I am used to Tecplot and like it. If visit could do the job that could also be OK. One problem with Visit is (and I have gone through the manual) is that it does not seem to have a way to deal with moving boundary problems when a different grid is output at each time step (as NEK does). Cheers, Frank On Mon, 2010-04-19 at 18:29 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > why do you want to use TecPlot? > I know sometime it's just because you don't want to dig into another tool. > However if there are other good reasons I am sure Hank will be quite interested to improve VisIt. > > Stefan > > > > On Apr 19, 2010, at 6:24 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Yes, I think a convert is the way to go. > > I will release at some point my old TecPlot convert however I need to fix a few things first. Unfortunately I am quite busy these days so it will take some time. > > > > Stefan > > > > > > On Apr 19, 2010, at 6:19 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Hello Stefan, > >> > >> Actually I would like to do that. I am quite familiar with I/O and > >> Tecplot and could make a writer that outputs their binary format files. > >> This could be done two ways, outputting directly from NEK to Tecplot > >> format files (and therefore not using the *.fld files for I/O) or > >> something that takes the *.fld files and creates Tecplot format files. > >> I tend to think the second is the best method as the issue of parallel > >> I/O is sidestepped. What is your opinion on this? > >> > >> Cheers, > >> Frank > >> > >> > >> On Mon, 2010-04-19 at 18:02 +0200, nek5000-users at lists.mcs.anl.gov > >> wrote: > >>> Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). > >>> If you know the data layout of NEK it's quite easy write your own convert. > >>> We did that for TecPlot some time ago. > >>> > >>> Stefan > >>> > >>> > >>> On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>> > >>>> Hi Stefan, > >>>> > >>>> Thanks. I had tried that. This translator appears to be a fairly rough > >>>> attempt to output data in Tecplot's format. It at times writes out > >>>> files that Tecplot cannot read. In addition, if dealing with temporal > >>>> data, there appears to be no way to write out the data at each time step > >>>> to a single Tecplot file. Therefore, one would need to do this > >>>> (exporting through the menus) for every file at every time step. > >>>> > >>>> Cheers, > >>>> Frank > >>>> > >>>> > >>>> On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov > >>>> wrote: > >>>>> Frank, > >>>>> > >>>>> read your data into VisIt and use the export option. > >>>>> I don't recall exactly what output formats they support but there are quite a few. > >>>>> > >>>>> Stefan > >>>>> > >>>>> > >>>>> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>>> > >>>>>> Hello all, > >>>>>> > >>>>>> Does anyone know of a way to translate *.fld files to a different format > >>>>>> (perhaps such as HDF, CGNS, Plot3D etc.)? > >>>>>> > >>>>>> Cheers, > >>>>>> Frank > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>>>>> Technische Universit?t Wien (Technical University of Vienna) > >>>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>>>>> Mechanics and Heat Transfer) > >>>>>> Resselgasse 3 > >>>>>> 1040 Wien > >>>>>> Tel: +4315880132232 > >>>>>> Fax: +4315880132299 > >>>>>> Cell:+436765203470 > >>>>>> fmuldoo (skype) > >>>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Nek5000-users mailing list > >>>>>> Nek5000-users at lists.mcs.anl.gov > >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>>> > >>>>> _______________________________________________ > >>>>> Nek5000-users mailing list > >>>>> Nek5000-users at lists.mcs.anl.gov > >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>> -- > >>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>>> Technische Universit?t Wien (Technical University of Vienna) > >>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>>> Mechanics and Heat Transfer) > >>>> Resselgasse 3 > >>>> 1040 Wien > >>>> Tel: +4315880132232 > >>>> Fax: +4315880132299 > >>>> Cell:+436765203470 > >>>> fmuldoo (skype) > >>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>>> > >>>> _______________________________________________ > >>>> Nek5000-users mailing list > >>>> Nek5000-users at lists.mcs.anl.gov > >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>> > >>> _______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> -- > >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >> Technische Universit?t Wien (Technical University of Vienna) > >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >> Mechanics and Heat Transfer) > >> Resselgasse 3 > >> 1040 Wien > >> Tel: +4315880132232 > >> Fax: +4315880132299 > >> Cell:+436765203470 > >> fmuldoo (skype) > >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:41:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:41:48 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> Message-ID: <1271695308.9761.10.camel@localhost.localdomain> On Mon, 2010-04-19 at 18:33 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > If you're interested in my old converter we could work together to improve it. Just led me know. Very interested. If you dig it up I'll take a look at it immediately. Cheers, Frank > > Stefan > > > > On Apr 19, 2010, at 6:19 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello Stefan, > > > > Actually I would like to do that. I am quite familiar with I/O and > > Tecplot and could make a writer that outputs their binary format files. > > This could be done two ways, outputting directly from NEK to Tecplot > > format files (and therefore not using the *.fld files for I/O) or > > something that takes the *.fld files and creates Tecplot format files. > > I tend to think the second is the best method as the issue of parallel > > I/O is sidestepped. What is your opinion on this? > > > > Cheers, > > Frank > > > > > > On Mon, 2010-04-19 at 18:02 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). > >> If you know the data layout of NEK it's quite easy write your own convert. > >> We did that for TecPlot some time ago. > >> > >> Stefan > >> > >> > >> On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hi Stefan, > >>> > >>> Thanks. I had tried that. This translator appears to be a fairly rough > >>> attempt to output data in Tecplot's format. It at times writes out > >>> files that Tecplot cannot read. In addition, if dealing with temporal > >>> data, there appears to be no way to write out the data at each time step > >>> to a single Tecplot file. Therefore, one would need to do this > >>> (exporting through the menus) for every file at every time step. > >>> > >>> Cheers, > >>> Frank > >>> > >>> > >>> On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov > >>> wrote: > >>>> Frank, > >>>> > >>>> read your data into VisIt and use the export option. > >>>> I don't recall exactly what output formats they support but there are quite a few. > >>>> > >>>> Stefan > >>>> > >>>> > >>>> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hello all, > >>>>> > >>>>> Does anyone know of a way to translate *.fld files to a different format > >>>>> (perhaps such as HDF, CGNS, Plot3D etc.)? > >>>>> > >>>>> Cheers, > >>>>> Frank > >>>>> > >>>>> > >>>>> -- > >>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>>>> Technische Universit?t Wien (Technical University of Vienna) > >>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>>>> Mechanics and Heat Transfer) > >>>>> Resselgasse 3 > >>>>> 1040 Wien > >>>>> Tel: +4315880132232 > >>>>> Fax: +4315880132299 > >>>>> Cell:+436765203470 > >>>>> fmuldoo (skype) > >>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>>>> > >>>>> _______________________________________________ > >>>>> Nek5000-users mailing list > >>>>> Nek5000-users at lists.mcs.anl.gov > >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>> > >>>> _______________________________________________ > >>>> Nek5000-users mailing list > >>>> Nek5000-users at lists.mcs.anl.gov > >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>> -- > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>> Technische Universit?t Wien (Technical University of Vienna) > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>> Mechanics and Heat Transfer) > >>> Resselgasse 3 > >>> 1040 Wien > >>> Tel: +4315880132232 > >>> Fax: +4315880132299 > >>> Cell:+436765203470 > >>> fmuldoo (skype) > >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>> > >>> _______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:46:45 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:46:45 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <1271695308.9761.10.camel@localhost.localdomain> References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> <1271695308.9761.10.camel@localhost.localdomain> Message-ID: I first need to rewrite the part discovering the mesh topology. I don't like the way it's coded now. I I'll send you something hopefully by the end of this week. Stefan On Apr 19, 2010, at 6:41 PM, nek5000-users at lists.mcs.anl.gov wrote: > On Mon, 2010-04-19 at 18:33 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Frank, >> >> If you're interested in my old converter we could work together to improve it. Just led me know. > > Very interested. If you dig it up I'll take a look at it immediately. > > Cheers, > Frank >> >> Stefan >> >> >> >> On Apr 19, 2010, at 6:19 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello Stefan, >>> >>> Actually I would like to do that. I am quite familiar with I/O and >>> Tecplot and could make a writer that outputs their binary format files. >>> This could be done two ways, outputting directly from NEK to Tecplot >>> format files (and therefore not using the *.fld files for I/O) or >>> something that takes the *.fld files and creates Tecplot format files. >>> I tend to think the second is the best method as the issue of parallel >>> I/O is sidestepped. What is your opinion on this? >>> >>> Cheers, >>> Frank >>> >>> >>> On Mon, 2010-04-19 at 18:02 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). >>>> If you know the data layout of NEK it's quite easy write your own convert. >>>> We did that for TecPlot some time ago. >>>> >>>> Stefan >>>> >>>> >>>> On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi Stefan, >>>>> >>>>> Thanks. I had tried that. This translator appears to be a fairly rough >>>>> attempt to output data in Tecplot's format. It at times writes out >>>>> files that Tecplot cannot read. In addition, if dealing with temporal >>>>> data, there appears to be no way to write out the data at each time step >>>>> to a single Tecplot file. Therefore, one would need to do this >>>>> (exporting through the menus) for every file at every time step. >>>>> >>>>> Cheers, >>>>> Frank >>>>> >>>>> >>>>> On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov >>>>> wrote: >>>>>> Frank, >>>>>> >>>>>> read your data into VisIt and use the export option. >>>>>> I don't recall exactly what output formats they support but there are quite a few. >>>>>> >>>>>> Stefan >>>>>> >>>>>> >>>>>> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> Does anyone know of a way to translate *.fld files to a different format >>>>>>> (perhaps such as HDF, CGNS, Plot3D etc.)? >>>>>>> >>>>>>> Cheers, >>>>>>> Frank >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>>>>> Technische Universit?t Wien (Technical University of Vienna) >>>>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>>>>> Mechanics and Heat Transfer) >>>>>>> Resselgasse 3 >>>>>>> 1040 Wien >>>>>>> Tel: +4315880132232 >>>>>>> Fax: +4315880132299 >>>>>>> Cell:+436765203470 >>>>>>> fmuldoo (skype) >>>>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Nek5000-users mailing list >>>>>>> Nek5000-users at lists.mcs.anl.gov >>>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>>> >>>>>> _______________________________________________ >>>>>> Nek5000-users mailing list >>>>>> Nek5000-users at lists.mcs.anl.gov >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>> -- >>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>>> Technische Universit?t Wien (Technical University of Vienna) >>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>>> Mechanics and Heat Transfer) >>>>> Resselgasse 3 >>>>> 1040 Wien >>>>> Tel: +4315880132232 >>>>> Fax: +4315880132299 >>>>> Cell:+436765203470 >>>>> fmuldoo (skype) >>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:57:18 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 09:57:18 -0700 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: <1271695210.9761.7.camel@localhost.localdomain> References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> <1271695210.9761.7.camel@localhost.localdomain> Message-ID: Hi Frank, You're exactly right about this. The problem isn't with VisIt, but with its Nek reader. We used to have it implemented so it could detect this case, but it was slow. Since we observed that much Nek usage doesn't have a moving mesh, we disabled it. It sounds like the Nek community is changing its usage of the code. I'll try to get this straightened out in VisIt. Best, Hank On Mon, Apr 19, 2010 at 9:40 AM, wrote: > Hi Stefan, > > Yes, that is pretty much it; I am used to Tecplot and like it. If visit > could do the job that could also be OK. One problem with Visit is (and > I have gone through the manual) is that it does not seem to have a way > to deal with moving boundary problems when a different grid is output at > each time step (as NEK does). > > Cheers, > Frank > > On Mon, 2010-04-19 at 18:29 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Frank, >> >> why do you want to use TecPlot? >> I know sometime it's just because you don't want to dig into another tool. >> However if there are other good reasons I am sure Hank will be quite interested to improve VisIt. >> >> Stefan >> >> >> >> On Apr 19, 2010, at 6:24 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >> > Yes, I think a convert is the way to go. >> > I will release at some point my old TecPlot convert however I need to fix a few things first. Unfortunately I am quite busy these days so it will take some time. >> > >> > Stefan >> > >> > >> > On Apr 19, 2010, at 6:19 PM, nek5000-users at lists.mcs.anl.gov wrote: >> > >> >> Hello Stefan, >> >> >> >> Actually I would like to do that. I am quite familiar with I/O and >> >> Tecplot and could make a writer that outputs their binary format files. >> >> This could be done two ways, outputting directly from NEK to Tecplot >> >> format files (and therefore not using the *.fld files for I/O) or >> >> something that takes the *.fld files and creates Tecplot format files. >> >> I tend to think the second is the best method as the issue of parallel >> >> I/O is sidestepped. What is your opinion on this? >> >> >> >> Cheers, >> >> Frank >> >> >> >> >> >> On Mon, 2010-04-19 at 18:02 +0200, nek5000-users at lists.mcs.anl.gov >> >> wrote: >> >>> Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). >> >>> If you know the data layout of NEK it's quite easy write your own convert. >> >>> We did that for TecPlot some time ago. >> >>> >> >>> Stefan >> >>> >> >>> >> >>> On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> >> >>>> Hi Stefan, >> >>>> >> >>>> Thanks. I had tried that. This translator appears to be a fairly rough >> >>>> attempt to output data in Tecplot's format. It at times writes out >> >>>> files that Tecplot cannot read. In addition, if dealing with temporal >> >>>> data, there appears to be no way to write out the data at each time step >> >>>> to a single Tecplot file. Therefore, one would need to do this >> >>>> (exporting through the menus) for every file at every time step. >> >>>> >> >>>> Cheers, >> >>>> Frank >> >>>> >> >>>> >> >>>> On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov >> >>>> wrote: >> >>>>> Frank, >> >>>>> >> >>>>> read your data into VisIt and use the export option. >> >>>>> I don't recall exactly what output formats they support but there are quite a few. >> >>>>> >> >>>>> Stefan >> >>>>> >> >>>>> >> >>>>> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>>>> >> >>>>>> Hello all, >> >>>>>> >> >>>>>> Does anyone know of a way to translate *.fld files to a different format >> >>>>>> (perhaps such as HDF, CGNS, Plot3D etc.)? >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Frank >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> >>>>>> Technische Universit?t Wien (Technical University of Vienna) >> >>>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> >>>>>> Mechanics and Heat Transfer) >> >>>>>> Resselgasse 3 >> >>>>>> 1040 Wien >> >>>>>> Tel: +4315880132232 >> >>>>>> Fax: +4315880132299 >> >>>>>> Cell:+436765203470 >> >>>>>> fmuldoo (skype) >> >>>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Nek5000-users mailing list >> >>>>>> Nek5000-users at lists.mcs.anl.gov >> >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Nek5000-users mailing list >> >>>>> Nek5000-users at lists.mcs.anl.gov >> >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >>>> -- >> >>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> >>>> Technische Universit?t Wien (Technical University of Vienna) >> >>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> >>>> Mechanics and Heat Transfer) >> >>>> Resselgasse 3 >> >>>> 1040 Wien >> >>>> Tel: +4315880132232 >> >>>> Fax: +4315880132299 >> >>>> Cell:+436765203470 >> >>>> fmuldoo (skype) >> >>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >>>> >> >>>> _______________________________________________ >> >>>> Nek5000-users mailing list >> >>>> Nek5000-users at lists.mcs.anl.gov >> >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >>> >> >>> _______________________________________________ >> >>> Nek5000-users mailing list >> >>> Nek5000-users at lists.mcs.anl.gov >> >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> -- >> >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> >> Technische Universit?t Wien (Technical University of Vienna) >> >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> >> Mechanics and Heat Transfer) >> >> Resselgasse 3 >> >> 1040 Wien >> >> Tel: +4315880132232 >> >> Fax: +4315880132299 >> >> Cell:+436765203470 >> >> fmuldoo (skype) >> >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> >> >> _______________________________________________ >> >> Nek5000-users mailing list >> >> Nek5000-users at lists.mcs.anl.gov >> >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > >> > _______________________________________________ >> > Nek5000-users mailing list >> > Nek5000-users at lists.mcs.anl.gov >> > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Apr 19 11:59:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 18:59:12 +0200 Subject: [Nek5000-users] *.fld files to ... In-Reply-To: References: <1271691042.5273.37.camel@localhost.localdomain> <1271692679.5273.44.camel@localhost.localdomain> <78847C6E-B285-4C60-B06F-02E3389E5165@lav.mavt.ethz.ch> <1271693940.9761.2.camel@localhost.localdomain> <1271695308.9761.10.camel@localhost.localdomain> Message-ID: <1271696352.9761.13.camel@localhost.localdomain> On Mon, 2010-04-19 at 18:46 +0200, nek5000-users at lists.mcs.anl.gov wrote: > I first need to rewrite the part discovering the mesh topology. I don't like the way it's coded now. I > I'll send you something hopefully by the end of this week. Hi Stefan, OK. One question, is this writer something that is part of NEK or something separate that transforms the *.fld files? Cheers, Frank > > > Stefan > > > On Apr 19, 2010, at 6:41 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > On Mon, 2010-04-19 at 18:33 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Frank, > >> > >> If you're interested in my old converter we could work together to improve it. Just led me know. > > > > Very interested. If you dig it up I'll take a look at it immediately. > > > > Cheers, > > Frank > >> > >> Stefan > >> > >> > >> > >> On Apr 19, 2010, at 6:19 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hello Stefan, > >>> > >>> Actually I would like to do that. I am quite familiar with I/O and > >>> Tecplot and could make a writer that outputs their binary format files. > >>> This could be done two ways, outputting directly from NEK to Tecplot > >>> format files (and therefore not using the *.fld files for I/O) or > >>> something that takes the *.fld files and creates Tecplot format files. > >>> I tend to think the second is the best method as the issue of parallel > >>> I/O is sidestepped. What is your opinion on this? > >>> > >>> Cheers, > >>> Frank > >>> > >>> > >>> On Mon, 2010-04-19 at 18:02 +0200, nek5000-users at lists.mcs.anl.gov > >>> wrote: > >>>> Yes you're right the export capabilities to TecPlot are quite limited (no multizone support, etc.). > >>>> If you know the data layout of NEK it's quite easy write your own convert. > >>>> We did that for TecPlot some time ago. > >>>> > >>>> Stefan > >>>> > >>>> > >>>> On Apr 19, 2010, at 5:57 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hi Stefan, > >>>>> > >>>>> Thanks. I had tried that. This translator appears to be a fairly rough > >>>>> attempt to output data in Tecplot's format. It at times writes out > >>>>> files that Tecplot cannot read. In addition, if dealing with temporal > >>>>> data, there appears to be no way to write out the data at each time step > >>>>> to a single Tecplot file. Therefore, one would need to do this > >>>>> (exporting through the menus) for every file at every time step. > >>>>> > >>>>> Cheers, > >>>>> Frank > >>>>> > >>>>> > >>>>> On Mon, 2010-04-19 at 17:34 +0200, nek5000-users at lists.mcs.anl.gov > >>>>> wrote: > >>>>>> Frank, > >>>>>> > >>>>>> read your data into VisIt and use the export option. > >>>>>> I don't recall exactly what output formats they support but there are quite a few. > >>>>>> > >>>>>> Stefan > >>>>>> > >>>>>> > >>>>>> On Apr 19, 2010, at 5:30 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>>>> > >>>>>>> Hello all, > >>>>>>> > >>>>>>> Does anyone know of a way to translate *.fld files to a different format > >>>>>>> (perhaps such as HDF, CGNS, Plot3D etc.)? > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Frank > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>>>>>> Technische Universit?t Wien (Technical University of Vienna) > >>>>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>>>>>> Mechanics and Heat Transfer) > >>>>>>> Resselgasse 3 > >>>>>>> 1040 Wien > >>>>>>> Tel: +4315880132232 > >>>>>>> Fax: +4315880132299 > >>>>>>> Cell:+436765203470 > >>>>>>> fmuldoo (skype) > >>>>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Nek5000-users mailing list > >>>>>>> Nek5000-users at lists.mcs.anl.gov > >>>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Nek5000-users mailing list > >>>>>> Nek5000-users at lists.mcs.anl.gov > >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>>> -- > >>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>>>> Technische Universit?t Wien (Technical University of Vienna) > >>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>>>> Mechanics and Heat Transfer) > >>>>> Resselgasse 3 > >>>>> 1040 Wien > >>>>> Tel: +4315880132232 > >>>>> Fax: +4315880132299 > >>>>> Cell:+436765203470 > >>>>> fmuldoo (skype) > >>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>>>> > >>>>> _______________________________________________ > >>>>> Nek5000-users mailing list > >>>>> Nek5000-users at lists.mcs.anl.gov > >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>> > >>>> _______________________________________________ > >>>> Nek5000-users mailing list > >>>> Nek5000-users at lists.mcs.anl.gov > >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>> -- > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>> Technische Universit?t Wien (Technical University of Vienna) > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>> Mechanics and Heat Transfer) > >>> Resselgasse 3 > >>> 1040 Wien > >>> Tel: +4315880132232 > >>> Fax: +4315880132299 > >>> Cell:+436765203470 > >>> fmuldoo (skype) > >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>> > >>> _______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 19 12:46:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 12:46:07 -0500 Subject: [Nek5000-users] Nek5000-users Digest, Vol 14, Issue 31 In-Reply-To: References: Message-ID: Hi Stefan, Is that the one that is given under the wiki ? If yes, I tried and was able to load the data points that I have. How do I mention that I want the velocities and pressures to be interpolated ? I believe the intpts routine needs that input .. Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 19 13:59:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 20:59:52 +0200 Subject: [Nek5000-users] Nek5000-users Digest, Vol 14, Issue 31 In-Reply-To: References: Message-ID: <1D9C1E76-B35F-459D-8EEC-1A3006968E29@lav.mavt.ethz.ch> Yes it's the first argument of intpts(). Stefan On Apr 19, 2010, at 7:46 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > Is that the one that is given under the wiki ? If yes, I tried and was able to load the data points that I have. How do I mention that I want the velocities and pressures to be interpolated ? I believe the intpts routine needs that input .. > > Regards > Shriram > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 16:20:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 23:20:16 +0200 Subject: [Nek5000-users] SETDTC message Message-ID: <1271712016.9761.21.camel@localhost.localdomain> Hello all, I am coming across the following message "Problem calculating new DT Discriminant" in subroutine "SETDTC" where a new timestep based on the CFL condition is computed. Aside from what the message means, how can one turn off variable time stepping (which I assume is occurring since this subroutine is being called). Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 19 16:27:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 16:27:50 -0500 (CDT) Subject: [Nek5000-users] SETDTC message In-Reply-To: <1271712016.9761.21.camel@localhost.localdomain> References: <1271712016.9761.21.camel@localhost.localdomain> Message-ID: Hi Frank, Set DT < 0 (param 12 in .rea file) and then dt = |param(12)| for the duration of the run. (Sometimes you still get the message though...) Paul On Mon, 19 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, I am coming across the following message "Problem calculating new DT Discriminant" in subroutine "SETDTC" where a new timestep based on the CFL condition is computed. Aside from what the message means, how can one turn off variable time stepping (which I assume is occurring since this subroutine is being called). Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 19 16:36:10 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 23:36:10 +0200 Subject: [Nek5000-users] SETDTC message In-Reply-To: References: <1271712016.9761.21.camel@localhost.localdomain> Message-ID: <1271712970.9761.26.camel@localhost.localdomain> Hi Paul, I always have dt < 0. In this case, that message can safely be ignored? By the way, if dt < 0, should this routine even be called? Cheers, Frank On Mon, 2010-04-19 at 16:27 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Set DT < 0 (param 12 in .rea file) and then dt = |param(12)| for > the duration of the run. (Sometimes you still get the message though...) > > Paul > > On Mon, 19 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > I am coming across the following message "Problem calculating new DT > Discriminant" in subroutine "SETDTC" where a new timestep based on the > CFL condition is computed. Aside from what the message means, how can > one turn off variable time stepping (which I assume is occurring since > this subroutine is being called). > > Cheers, > Frank > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Mon Apr 19 16:41:43 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 19 Apr 2010 16:41:43 -0500 (CDT) Subject: [Nek5000-users] SETDTC message In-Reply-To: <1271712970.9761.26.camel@localhost.localdomain> References: <1271712016.9761.21.camel@localhost.localdomain> <1271712970.9761.26.camel@localhost.localdomain> Message-ID: Hi Frank, Yes - the message can be ignored. (Sorry about that..., probably one of those things that will be cleaned up in the next major revision...) It's nice to call the routine so that CFL is computed, just so you know where you stand... Paul On Mon, 19 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, I always have dt < 0. In this case, that message can safely be ignored? By the way, if dt < 0, should this routine even be called? Cheers, Frank On Mon, 2010-04-19 at 16:27 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Set DT < 0 (param 12 in .rea file) and then dt = |param(12)| for > the duration of the run. (Sometimes you still get the message though...) > > Paul > > On Mon, 19 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > I am coming across the following message "Problem calculating new DT > Discriminant" in subroutine "SETDTC" where a new timestep based on the > CFL condition is computed. Aside from what the message means, how can > one turn off variable time stepping (which I assume is occurring since > this subroutine is being called). > > Cheers, > Frank > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Apr 20 05:00:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 Apr 2010 12:00:06 +0200 Subject: [Nek5000-users] Trouble using cylindrical mesh Message-ID: <4BCD7B26.2010701@gmail.com> Hello all, I have a few problems when using the blah.box template from the Nek 5000 Primer guide for cylindrical meshes. Here is the error message I get: =================================================================================== Number of processors: 1 REAL wdsize : 8 INTEGER wdsize : 4 Beginning session: /home/loiseau/BricoNek/Cylindre/Cylindre.rea timer accuracy: 0.0000000E+00 sec read .rea file nelgt/nelgv/lelt: 72 72 80 lx1 /lx2 /lx3 : 6 4 4 mapping elements to processors 0 72 72 72 72 NELV RANK 0 IEG 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 done :: mapping elements to processors ERROR READING MESH DATA NEAR ELEMENT 1 ABORTING IN ROUTINE RDMESH. call exitt: dying ... backtrace(): obtained 9 stack frames. ./nek5000 [0x551d88] ./nek5000 [0x653f02] ./nek5000 [0x44202e] ./nek5000 [0x43d215] ./nek5000 [0x403b32] ./nek5000 [0x403a8e] ./nek5000 [0x40389c] /lib64/libc.so.6(__libc_start_main+0xf4) [0x3393c1d974] ./nek5000 [0x4037a9] total elapsed time : 0.00000E+00 sec total solver time incl. I/O : 0.00000E+00 sec time/timestep : 0.00000E+00 sec CPU seconds/timestep/DOF : 0.00000E+00 sec =================================================================================== Attached are all the files I've been using. I also have a question concerning the descriptors line in the .box file. =================================================================================== Cyl.rea 2 Spatial dimension 1 number of fields # # # Y cYlinder 3 -24 1 nelr, nel-theta, nelz .5 .3 x0, y0 ccbb descriptors: c-cyl, o-oct, b-box .5 .55 .7 .8 r0 ... r_nelr 0 1 1 theta0/2pi theta1/2pi ratio v ,W ,E ,E , BC =================================================================================== What does the ccbb line stands for ? If I wanna mesh the cross section of a cylindrical pipe and then extrude it to a 3D mesh using n2to3, what descriptors should I use ? Regards, Jean-Christophe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Cyl.rea URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Cylindre.box URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Cylindre.rea URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Cylindre.usr URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SIZE URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: instruction.pdf Type: application/pdf Size: 169670 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 20 05:38:17 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 Apr 2010 05:38:17 -0500 (CDT) Subject: [Nek5000-users] Trouble using cylindrical mesh In-Reply-To: <4BCD7B26.2010701@gmail.com> References: <4BCD7B26.2010701@gmail.com> Message-ID: Jean-Christophe, Please try the latest repo for the nek source - there was a formatting issue with reading the input. cd nek5_svn/trunk mv nek nek487 svn update nek should work. Paul On Tue, 20 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I have a few problems when using the blah.box template from the Nek 5000 > Primer guide for cylindrical meshes. > Here is the error message I get: > > =================================================================================== > > Number of processors: 1 > REAL wdsize : 8 > INTEGER wdsize : 4 > > > Beginning session: > /home/loiseau/BricoNek/Cylindre/Cylindre.rea > > > timer accuracy: 0.0000000E+00 sec > > read .rea file > nelgt/nelgv/lelt: 72 72 80 > lx1 /lx2 /lx3 : 6 4 4 > > mapping elements to processors > 0 72 72 72 72 NELV > RANK 0 IEG 1 2 3 4 5 6 7 > 8 > 9 10 11 12 13 14 15 > 16 > 17 18 19 20 21 22 23 > 24 > 25 26 27 28 29 30 31 > 32 > 33 34 35 36 37 38 39 > 40 > 41 42 43 44 45 46 47 > 48 > 49 50 51 52 53 54 55 > 56 > 57 58 59 60 61 62 63 > 64 > 65 66 67 68 69 70 71 > 72 > done :: mapping elements to processors > > ERROR READING MESH DATA NEAR ELEMENT 1 > ABORTING IN ROUTINE RDMESH. > > call exitt: dying ... > > backtrace(): obtained 9 stack frames. > ./nek5000 [0x551d88] > ./nek5000 [0x653f02] > ./nek5000 [0x44202e] > ./nek5000 [0x43d215] > ./nek5000 [0x403b32] > ./nek5000 [0x403a8e] > ./nek5000 [0x40389c] > /lib64/libc.so.6(__libc_start_main+0xf4) [0x3393c1d974] > ./nek5000 [0x4037a9] > > total elapsed time : 0.00000E+00 sec > total solver time incl. I/O : 0.00000E+00 sec > time/timestep : 0.00000E+00 sec > CPU seconds/timestep/DOF : 0.00000E+00 sec > > =================================================================================== > > Attached are all the files I've been using. > > I also have a question concerning the descriptors line in the .box file. > > =================================================================================== > > Cyl.rea > 2 Spatial dimension > 1 number of fields > # > # > # > Y cYlinder > 3 -24 1 nelr, nel-theta, nelz > .5 .3 x0, y0 > ccbb descriptors: c-cyl, o-oct, b-box > .5 .55 .7 .8 r0 ... r_nelr > 0 1 1 theta0/2pi theta1/2pi ratio > v ,W ,E ,E , BC > > =================================================================================== > > What does the ccbb line stands for ? > If I wanna mesh the cross section of a cylindrical pipe and then extrude it > to a 3D mesh using n2to3, what descriptors should I use ? > > Regards, > > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Tue Apr 20 13:31:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 Apr 2010 13:31:49 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description Message-ID: <1943349515.9851731271788309388.JavaMail.root@neo-mail-3> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 20 13:55:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 Apr 2010 20:55:41 +0200 Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <1943349515.9851731271788309388.JavaMail.root@neo-mail-3> References: <1943349515.9851731271788309388.JavaMail.root@neo-mail-3> Message-ID: <1271789741.31181.17.camel@localhost.localdomain> Hi Michael, I get this error when using a too large time step with a moving free surface problem. The problem being that the mesh deforms excessively. Are you working on a moving boundary problem? Cheers, Frank On Tue, 2010-04-20 at 13:31 -0500, nek5000-users at lists.mcs.anl.gov 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 > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Tue Apr 20 15:36:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 20 Apr 2010 15:36:44 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <1943349515.9851731271788309388.JavaMail.root@neo-mail-3> References: <1943349515.9851731271788309388.JavaMail.root@neo-mail-3> Message-ID: 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, nek5000-users at lists.mcs.anl.gov 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 > > > > > > From nek5000-users at lists.mcs.anl.gov Wed Apr 21 06:52:26 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 13:52:26 +0200 Subject: [Nek5000-users] Visit and NEK 3D data Message-ID: <1271850746.31181.40.camel@localhost.localdomain> Hello all, I am running into a problem with Visit and NEK 3D data files. Visit (version 1.12.2) reads them in, but the mesh is all jumbled up. If anyone could try Visit on this file, I'd be grateful, perhaps there is some setting in Visit that I overlooked. The data file (4MB) is: http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d.fld01 I use the following meta data file: NEK5000 version: 1.0 filetemplate: c203d.fld%02d firsttimestep: 2 numtimesteps: 1 Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 21 06:54:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 13:54:55 +0200 Subject: [Nek5000-users] Visit and NEK 3D data In-Reply-To: <1271850746.31181.40.camel@localhost.localdomain> References: <1271850746.31181.40.camel@localhost.localdomain> Message-ID: <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> Hi, is there a reason why you don't want to use the *.f???? binary format? Stefan On Apr 21, 2010, at 1:52 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I am running into a problem with Visit and NEK 3D data files. Visit > (version 1.12.2) reads them in, but the mesh is all jumbled up. If > anyone could try Visit on this file, I'd be grateful, perhaps there is > some setting in Visit that I overlooked. > > The data file (4MB) is: > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d.fld01 > > I use the following meta data file: > NEK5000 > version: 1.0 > filetemplate: c203d.fld%02d > firsttimestep: 2 > numtimesteps: 1 > > > Cheers, > Frank > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 06:56:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 13:56:09 +0200 Subject: [Nek5000-users] Visit and NEK 3D data In-Reply-To: <1271850746.31181.40.camel@localhost.localdomain> References: <1271850746.31181.40.camel@localhost.localdomain> Message-ID: There is no mesh in this fld-file? Stefan On Apr 21, 2010, at 1:52 PM, nek5000-users at lists.mcs.anl.gov wrote: > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d.fld01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 06:58:06 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 13:58:06 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi Message-ID: <1271851086.31181.46.camel@localhost.localdomain> Hello all, I am seeing the following error message when I use an mpif77 and mpicc that use the Sun compilers. Everything is fine if in makenek F77=sunf95 and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use the Intel compilers. Cheers, Frank sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored otherwise Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details WARNING: Cannot detect compiler specfic flags echo - to promote REAL to 8 bytes echo - to invoke preprocessor first Please edit the makefile and specify the requested compiler flags in the P variable! -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:00:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 14:00:48 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: <1271851086.31181.46.camel@localhost.localdomain> References: <1271851086.31181.46.camel@localhost.localdomain> Message-ID: <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> What MPI implementation are you using? Stefan On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I am seeing the following error message when I use an mpif77 and mpicc > that use the Sun compilers. Everything is fine if in makenek F77=sunf95 > and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use > the Intel compilers. > > Cheers, > Frank > > > sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored > otherwise > Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details > WARNING: Cannot detect compiler specfic flags > echo - to promote REAL to 8 bytes > echo - to invoke preprocessor first > Please edit the makefile and specify the requested compiler flags in the > P variable! > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:01:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 07:01:16 -0500 (CDT) Subject: [Nek5000-users] Visit and NEK 3D data In-Reply-To: References: <1271850746.31181.40.camel@localhost.localdomain> Message-ID: Hi Frank, I forgot to put geometry in the .fld file... Just set ifxyo=.true. if (istep.gt.iostep) ifxyo=.false. in userchk() and you should be set. Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > There is no mesh in this fld-file? > > Stefan > > > On Apr 21, 2010, at 1:52 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d.fld01 > > From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:02:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 14:02:21 +0200 Subject: [Nek5000-users] Visit and NEK 3D data In-Reply-To: <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> Message-ID: <1271851341.31181.50.camel@localhost.localdomain> Hi Stefan, I am not sure exactly what that format "*.f????" is. In "usrdat2" I have: param(66) = 4. ! These give the std nek binary i/o and are param(67) = 4. ! good default values There are two different binary formats? Cheers, Frank On Wed, 2010-04-21 at 13:54 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > is there a reason why you don't want to use the *.f???? binary format? > > Stefan > > > On Apr 21, 2010, at 1:52 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > > > I am running into a problem with Visit and NEK 3D data files. Visit > > (version 1.12.2) reads them in, but the mesh is all jumbled up. If > > anyone could try Visit on this file, I'd be grateful, perhaps there is > > some setting in Visit that I overlooked. > > > > The data file (4MB) is: > > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d.fld01 > > > > I use the following meta data file: > > NEK5000 > > version: 1.0 > > filetemplate: c203d.fld%02d > > firsttimestep: 2 > > numtimesteps: 1 > > > > > > Cheers, > > Frank > > > > > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:04:04 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 07:04:04 -0500 (CDT) Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> References: <1271851086.31181.46.camel@localhost.localdomain> <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> Message-ID: When I used to use the sun in the past, the correct flags were: -r8 -i4 -fnonstd Note that i4 after r8 is mandatory (not before r8 and not left out... ) Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > What MPI implementation are you using? > > Stefan > > > On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello all, >> >> I am seeing the following error message when I use an mpif77 and mpicc >> that use the Sun compilers. Everything is fine if in makenek F77=sunf95 >> and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use >> the Intel compilers. >> >> Cheers, >> Frank >> >> >> sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored >> otherwise >> Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details >> WARNING: Cannot detect compiler specfic flags >> echo - to promote REAL to 8 bytes >> echo - to invoke preprocessor first >> Please edit the makefile and specify the requested compiler flags in the >> P variable! >> >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 >> Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:04:31 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 14:04:31 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> References: <1271851086.31181.46.camel@localhost.localdomain> <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> Message-ID: <1271851471.31181.53.camel@localhost.localdomain> Hi Stefan, I have tried both mpich-1.2.7p1 and mpich2-1.2.1p1. Same problem though. On Wed, 2010-04-21 at 14:00 +0200, nek5000-users at lists.mcs.anl.gov wrote: > What MPI implementation are you using? > > Stefan > > > On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > > > I am seeing the following error message when I use an mpif77 and mpicc > > that use the Sun compilers. Everything is fine if in makenek F77=sunf95 > > and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use > > the Intel compilers. > > > > Cheers, > > Frank > > > > > > sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored > > otherwise > > Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details > > WARNING: Cannot detect compiler specfic flags > > echo - to promote REAL to 8 bytes > > echo - to invoke preprocessor first > > Please edit the makefile and specify the requested compiler flags in the > > P variable! > > > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:05:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 07:05:16 -0500 (CDT) Subject: [Nek5000-users] Visit and NEK 3D data In-Reply-To: <1271851341.31181.50.camel@localhost.localdomain> References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> Message-ID: Hi Frank, the .f.... format is associated with our parallel i/o, but also works in serial. However, it doesn't work w/ postx (if you're using that...) Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, I am not sure exactly what that format "*.f????" is. In "usrdat2" I have: param(66) = 4. ! These give the std nek binary i/o and are param(67) = 4. ! good default values There are two different binary formats? Cheers, Frank On Wed, 2010-04-21 at 13:54 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > is there a reason why you don't want to use the *.f???? binary format? > > Stefan > > > On Apr 21, 2010, at 1:52 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > > > I am running into a problem with Visit and NEK 3D data files. Visit > > (version 1.12.2) reads them in, but the mesh is all jumbled up. If > > anyone could try Visit on this file, I'd be grateful, perhaps there is > > some setting in Visit that I overlooked. > > > > The data file (4MB) is: > > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d.fld01 > > > > I use the following meta data file: > > NEK5000 > > version: 1.0 > > filetemplate: c203d.fld%02d > > firsttimestep: 2 > > numtimesteps: 1 > > > > > > Cheers, > > Frank > > > > > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:06:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 14:06:53 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: References: <1271851086.31181.46.camel@localhost.localdomain> <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> Message-ID: No these flags are _not_ need. The problem is somewhere else! Stefan On Apr 21, 2010, at 2:04 PM, nek5000-users at lists.mcs.anl.gov wrote: > > When I used to use the sun in the past, the correct flags > were: > > -r8 -i4 -fnonstd > > > Note that i4 after r8 is mandatory (not before r8 and not > left out... ) > > Paul > > > On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> What MPI implementation are you using? >> >> Stefan >> >> >> On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >>> >>> I am seeing the following error message when I use an mpif77 and mpicc >>> that use the Sun compilers. Everything is fine if in makenek F77=sunf95 >>> and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use >>> the Intel compilers. >>> >>> Cheers, >>> Frank >>> >>> >>> sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored >>> otherwise >>> Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details >>> WARNING: Cannot detect compiler specfic flags >>> echo - to promote REAL to 8 bytes >>> echo - to invoke preprocessor first >>> Please edit the makefile and specify the requested compiler flags in the >>> P variable! >>> >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:09:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 14:09:44 +0200 Subject: [Nek5000-users] Visit and NEK 3D data In-Reply-To: References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> Message-ID: Note the *.f???? is the recommended data format for production runs! A lot of features and optimizations are only available for the *.f???? format. The only problem is that some tools like postx,prex do not support the *.f???? format. However you can use NEK to convert one format into another one. Stefan On Apr 21, 2010, at 2:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Frank, > > the .f.... format is associated with our parallel i/o, but > also works in serial. However, it doesn't work w/ postx > (if you're using that...) > > Paul > > > On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Stefan, > > I am not sure exactly what that format "*.f????" is. In "usrdat2" I > have: > > param(66) = 4. ! These give the std nek binary i/o and are > param(67) = 4. ! good default values > > There are two different binary formats? > > Cheers, > Frank > > > > On Wed, 2010-04-21 at 13:54 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi, >> is there a reason why you don't want to use the *.f???? binary format? >> Stefan >> On Apr 21, 2010, at 1:52 PM, nek5000-users at lists.mcs.anl.gov wrote: >> > Hello all, >> > > I am running into a problem with Visit and NEK 3D data files. Visit >> > (version 1.12.2) reads them in, but the mesh is all jumbled up. If >> > anyone could try Visit on this file, I'd be grateful, perhaps there is >> > some setting in Visit that I overlooked. > > The data file (4MB) is: >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d.fld01 >> > > I use the following meta data file: >> > NEK5000 >> > version: 1.0 >> > filetemplate: c203d.fld%02d >> > firsttimestep: 2 >> > numtimesteps: 1 >> > > > Cheers, >> > Frank >> > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> > Technische Universit?t Wien (Technical University of Vienna) >> > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> > Mechanics and Heat Transfer) >> > Resselgasse 3 >> > 1040 Wien >> > Tel: +4315880132232 >> > Fax: +4315880132299 > Cell:+436765203470 >> > fmuldoo (skype) >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> > > _______________________________________________ >> > Nek5000-users mailing list >> > Nek5000-users at lists.mcs.anl.gov >> > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users_______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:25:35 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 14:25:35 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> References: <1271851086.31181.46.camel@localhost.localdomain> <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> Message-ID: Ok I think what happens is the following: We need to detect which compilers are used by the MPI-wrappers. Depending on the MPI implementation there are some flags (e.g. -showme / -show) you can use to figure that out. MPICH doesn't know the flag -showme hence it is passed to the compiler (in your case sunf95). The sun compiler says this is an unknown flag and returns a ZERO exit code. This is weird if not to say wrong because you would assume that the right exit code should be NON-ZERO in this case! It looks like only the SUN compiler behaves wrong in this situation. Unfortunately I don't have access to machine with MPICH/SUN so I cannot test my hypothesis. Stefan On Apr 21, 2010, at 2:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > What MPI implementation are you using? > > Stefan > > > On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello all, >> >> I am seeing the following error message when I use an mpif77 and mpicc >> that use the Sun compilers. Everything is fine if in makenek F77=sunf95 >> and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use >> the Intel compilers. >> >> Cheers, >> Frank >> >> >> sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored >> otherwise >> Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details >> WARNING: Cannot detect compiler specfic flags >> echo - to promote REAL to 8 bytes >> echo - to invoke preprocessor first >> Please edit the makefile and specify the requested compiler flags in the >> P variable! >> >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 >> Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 07:29:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 14:29:38 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: References: <1271851086.31181.46.camel@localhost.localdomain> <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> Message-ID: <833BA88D-5DB6-4AEC-945D-F077AAF7C5BD@lav.mavt.ethz.ch> Note the whole mess started because OpenMPI uses -showme instead of -show. They did that because there was a potential conflict with an internal compilers flag -show used by PGI. Unfortunately the MPI standard doesn't say anything about the wrapper flags. It only suggest some features but all depends at the end on the specific MPI implementation. Stefan On Apr 21, 2010, at 2:25 PM, nek5000-users at lists.mcs.anl.gov wrote: > Ok I think what happens is the following: > > We need to detect which compilers are used by the MPI-wrappers. Depending on the MPI implementation there are some flags (e.g. -showme / -show) you can use to figure that out. > > MPICH doesn't know the flag -showme hence it is passed to the compiler (in your case sunf95). > The sun compiler says this is an unknown flag and returns a ZERO exit code. > This is weird if not to say wrong because you would assume that the right exit code should be NON-ZERO in this case! > > It looks like only the SUN compiler behaves wrong in this situation. > Unfortunately I don't have access to machine with MPICH/SUN so I cannot test my hypothesis. > > Stefan > > > On Apr 21, 2010, at 2:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> What MPI implementation are you using? >> >> Stefan >> >> >> On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >>> >>> I am seeing the following error message when I use an mpif77 and mpicc >>> that use the Sun compilers. Everything is fine if in makenek F77=sunf95 >>> and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use >>> the Intel compilers. >>> >>> Cheers, >>> Frank >>> >>> >>> sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored >>> otherwise >>> Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details >>> WARNING: Cannot detect compiler specfic flags >>> echo - to promote REAL to 8 bytes >>> echo - to invoke preprocessor first >>> Please edit the makefile and specify the requested compiler flags in the >>> P variable! >>> >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 08:04:19 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 08:04:19 -0500 (CDT) Subject: [Nek5000-users] Visit and NEK 3D data In-Reply-To: Message-ID: <1176035372.10203391271855059096.JavaMail.root@neo-mail-3> Hi, I ran into a similar issue when using *.f???? file formats and visit, however when I loaded the mesh nothing would show up. I switched it to *.fld and then it started showing up, no other changes.? Have you seen this before? Also Paul,? Sorry I haven't sent over the rea/usr files yet, I had left for the day and had trouble connecting to our server last night. I will send them out this morning. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, April 21, 2010 7:09:44 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Visit and NEK 3D data Note the *.f???? is the recommended data format for production runs! A lot of features and optimizations are only available for the *.f???? format. The only problem is that some tools like postx,prex do not support the *.f???? format. However you can use NEK to convert one format into another one. Stefan On Apr 21, 2010, at 2:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Frank, > > the .f.... format is associated with our parallel i/o, but > also works in serial. ? However, it doesn't work w/ postx > (if you're using that...) > > Paul > > > On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Stefan, > > I am not sure exactly what that format "*.f????" is. ?In "usrdat2" I > have: > > ? ? ?param(66) = 4. ? ! These give the std nek binary i/o and are > ? ? ?param(67) = 4. ? ! good default values > > There are two different binary formats? > > Cheers, > Frank > > > > On Wed, 2010-04-21 at 13:54 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi, >> is there a reason why you don't want to use the *.f???? binary format? >> Stefan >> On Apr 21, 2010, at 1:52 PM, nek5000-users at lists.mcs.anl.gov wrote: >> > Hello all, >> > > I am running into a problem with Visit and NEK 3D data files. ?Visit >> > (version 1.12.2) reads them in, but the mesh is all jumbled up. ?If >> > anyone could try Visit on this file, I'd be grateful, perhaps there is >> > some setting in Visit that I overlooked. > > The data file (4MB) is: >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d.fld01 >> > > I use the following meta data file: >> > NEK5000 >> > version: 1.0 >> > filetemplate: ?c203d.fld%02d >> > firsttimestep: 2 >> > numtimesteps: 1 >> > > > Cheers, >> > Frank >> > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> > Technische Universit?t Wien (Technical University of Vienna) >> > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> > Mechanics and Heat Transfer) >> > Resselgasse 3 >> > 1040 Wien >> > Tel: +4315880132232 >> > Fax: +4315880132299 > Cell:+436765203470 >> > fmuldoo (skype) >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> > > _______________________________________________ >> > Nek5000-users mailing list >> > Nek5000-users at lists.mcs.anl.gov >> > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users_______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 08:06:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 15:06:16 +0200 Subject: [Nek5000-users] Visit and NEK 3D data In-Reply-To: <1176035372.10203391271855059096.JavaMail.root@neo-mail-3> References: <1176035372.10203391271855059096.JavaMail.root@neo-mail-3> Message-ID: <4BCBFB53-BE1F-4C06-A18E-6ED7D28DC69F@lav.mavt.ethz.ch> Everything works fine over here. Any chance to get access to the .f???? file you're referring to? Stefan On Apr 21, 2010, at 3:04 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I ran into a similar issue when using *.f???? file formats and visit, however when I loaded the mesh nothing would show up. I switched it to *.fld and then it started showing up, no other changes. Have you seen this before? > > Also Paul, > > Sorry I haven't sent over the rea/usr files yet, I had left for the day and had trouble connecting to our server last night. I will send them out this morning. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 7:09:44 AM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] Visit and NEK 3D data > > Note the *.f???? is the recommended data format for production runs! > A lot of features and optimizations are only available for the *.f???? format. > > The only problem is that some tools like postx,prex do not support the *.f???? format. However you can use NEK to convert one format into another one. > > Stefan > > > On Apr 21, 2010, at 2:05 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > > > Hi Frank, > > > > the .f.... format is associated with our parallel i/o, but > > also works in serial. However, it doesn't work w/ postx > > (if you're using that...) > > > > Paul > > > > > > On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Hi Stefan, > > > > I am not sure exactly what that format "*.f????" is. In "usrdat2" I > > have: > > > > param(66) = 4. ! These give the std nek binary i/o and are > > param(67) = 4. ! good default values > > > > There are two different binary formats? > > > > Cheers, > > Frank > > > > > > > > On Wed, 2010-04-21 at 13:54 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi, > >> is there a reason why you don't want to use the *.f???? binary format? > >> Stefan > >> On Apr 21, 2010, at 1:52 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > Hello all, > >> > > I am running into a problem with Visit and NEK 3D data files. Visit > >> > (version 1.12.2) reads them in, but the mesh is all jumbled up. If > >> > anyone could try Visit on this file, I'd be grateful, perhaps there is > >> > some setting in Visit that I overlooked. > > The data file (4MB) is: > >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d.fld01 > >> > > I use the following meta data file: > >> > NEK5000 > >> > version: 1.0 > >> > filetemplate: c203d.fld%02d > >> > firsttimestep: 2 > >> > numtimesteps: 1 > >> > > > Cheers, > >> > Frank > >> > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >> > Technische Universit?t Wien (Technical University of Vienna) > >> > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >> > Mechanics and Heat Transfer) > >> > Resselgasse 3 > >> > 1040 Wien > >> > Tel: +4315880132232 > >> > Fax: +4315880132299 > Cell:+436765203470 > >> > fmuldoo (skype) > >> > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >> > > _______________________________________________ > >> > Nek5000-users mailing list > >> > Nek5000-users at lists.mcs.anl.gov > >> > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users_______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 08:30:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 08:30:53 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <2015398684.10208111271856562336.JavaMail.root@neo-mail-3> Message-ID: <535225313.10208711271856653391.JavaMail.root@neo-mail-3> 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: nek5000-users at lists.mcs.anl.gov To: "Nekton User List" 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, nek5000-users at lists.mcs.anl.gov 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 Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.tar Type: application/x-tar Size: 11200 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.tar.bz2 Type: application/x-bzip-compressed-tar Size: 11200 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 08:39:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 08:39:38 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <535225313.10208711271856653391.JavaMail.root@neo-mail-3> References: <535225313.10208711271856653391.JavaMail.root@neo-mail-3> Message-ID: The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > 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, nek5000-users at lists.mcs.anl.gov 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 > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Apr 21 08:07:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 09:07:21 -0400 Subject: [Nek5000-users] Residuals for post-processing Message-ID: <4BCEF889.1050105@vt.edu> Hi, I'd like to save the residuals for the pressure iterations (PN/PN-2 as well as PN/PN) into a scalar variable (scalar 0, instead of temperature say) for each grid point in order to see where my solution diverges. Is there a way to add something to the .usr file to do that? I couldn't find the variable in the code and also wouldn't know how to save something from the lx2=lx1-2 grid onto the lx1 grid. Would this also be possible with the velocity residuals? Thanks, Markus From nek5000-users at lists.mcs.anl.gov Wed Apr 21 09:19:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 09:19:46 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <1740560264.10223541271859584071.JavaMail.root@neo-mail-3> Message-ID: <679557729.10223601271859586450.JavaMail.root@neo-mail-3> Hi, Sorry, yes that was for without the curve side data. Here is the case that includes the curved side data. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, April 21, 2010 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Vanishing Jacobian error description The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > 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, nek5000-users at lists.mcs.anl.gov 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 > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test2.tar Type: application/x-tar Size: 12448 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 09:27:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 09:27:12 -0500 (CDT) Subject: [Nek5000-users] Residuals for post-processing In-Reply-To: <4BCEF889.1050105@vt.edu> References: <4BCEF889.1050105@vt.edu> Message-ID: Hi Markus, pressure residuals are in gmres You could output them via: call outpost(x,y,z,res,t,'res') where x,y,z,t are arrays of your choice and res is the array you want to look at. Nek will convert the res mesh to the velocity mesh if needed. I usually follow such a call with call exitti('quit in gmres$',n) because prepost() uses some scratch common blocks that are potentially shared with the calling routine (not in the case of gmres, I think...) -- so data might be corrupted after such a call. The idea of prepost was to be called in between timesteps, when such memory re-use would be admissable. The alternative would be to define your own storage in a common block, save the residuals to this locale, then loop through calls to outpost in userchk afterwards... I've done that in the past. All this being said, I'm not 100% certain that the iterative solvers is the place to look for the difficulty. Most problems arise from spatial resolution issues...or temporal stability problems. The latter can be identified by drastic reduction in dt. What exactly is blowing up for you? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I'd like to save the residuals for the pressure iterations (PN/PN-2 as well > as PN/PN) into a scalar variable (scalar 0, instead of temperature say) for > each grid point in order to see where my solution diverges. > Is there a way to add something to the .usr file to do that? I couldn't find > the variable in the code and also wouldn't know how to save something from > the lx2=lx1-2 grid onto the lx1 grid. > Would this also be possible with the velocity residuals? > > Thanks, > Markus > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > uuuu c----------------------------------------------------------------------- subroutine uzawa_gmres(res,h1,h2,h2inv,intype,iter) c Solve the pressure equation by right-preconditioned c GMRES iteration. c intype = 0 (steady) c intype = 1 (explicit) c intype = -1 (implicit) include 'SIZE' include 'TOTAL' include 'GMRES' common /ctolpr/ divex common /cprint/ ifprint logical ifprint real res (lx2*ly2*lz2*lelv) real h1 (lx1,ly1,lz1,lelv) real h2 (lx1,ly1,lz1,lelv) real h2inv(lx1,ly1,lz1,lelv) common /scrmg/ wp (lx2,ly2,lz2,lelv) common /ctmp0/ wk1(lgmres),wk2(lgmres) common /cgmres1/ y(lgmres) real alpha, l, temp integer j,m c logical iflag save iflag data iflag /.false./ real norm_fac save norm_fac c real*8 etime1,dnekclock c if(.not.iflag) then iflag=.true. call uzawa_gmres_split0(ml,mu,bm2,bm2inv,nx2*ny2*nz2*nelv) norm_fac = 1./sqrt(volvm2) endif c etime1 = dnekclock() etime_p = 0. divex = 0. iter = 0 m = lgmres c call chktcg2(tolps,res,iconv) if (param(21).gt.0.and.tolps.gt.abs(param(21))) $ tolps = abs(param(21)) c if (param(21).lt.0) tolps = abs(param(21)) if (istep.eq.0) tolps = 1.e-4 tolpss = tolps c ntot2 = nx2*ny2*nz2*nelv c iconv = 0 call rzero(x,ntot2) do while(iconv.eq.0.and.iter.lt.100) if(iter.eq.0) then ! -1 call col3(r,ml,res,ntot2) ! r = L res c call copy(r,res,ntot2) else !update residual call copy(r,res,ntot2) ! r = res call cdabdtp(w,x,h1,h2,h2inv,intype) ! w = A x call add2s2(r,w,-1.,ntot2) ! r = r - w ! -1 call col2(r,ml,ntot2) ! r = L r endif ! ______ gamma(1) = sqrt(glsc2(r,r,ntot2)) ! gamma = \/ (r,r) ! 1 if(iter.eq.0) then div0 = gamma(1)*norm_fac if (param(21).lt.0) tolpss=abs(param(21))*div0 endif !check for lucky convergence rnorm = 0. if(gamma(1) .eq. 0.) goto 9000 temp = 1./gamma(1) call cmult2(v(1,1),r,temp,ntot2) ! v = r / gamma ! 1 1 do j=1,m iter = iter+1 ! -1 call col3(w,mu,v(1,j),ntot2) ! w = U v ! j etime2 = dnekclock() if(param(43).eq.1) then call uzprec(z(1,j),w,h1,h2,intype,wp) else ! -1 call hsmg_solve(z(1,j),w) ! z = M w endif etime_p = etime_p + dnekclock()-etime2 call cdabdtp(w,z(1,j), ! w = A z $ h1,h2,h2inv,intype) ! j ! -1 call col2(w,ml,ntot2) ! w = L w c !modified Gram-Schmidt c do i=1,j c h(i,j)=glsc2(w,v(1,i),ntot2) ! h = (w,v ) c ! i,j i c call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v c enddo ! i,j i c 2-PASS GS, 1st pass: do i=1,j h(i,j)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) enddo ! i,j i call gop(h(1,j),wk1,'+ ',j) ! sum over P procs do i=1,j call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v enddo ! i,j i c 2-PASS GS, 2nd pass: c c do i=1,j c wk1(i)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) c enddo ! i,j i c ! c call gop(wk1,wk2,'+ ',j) ! sum over P procs c c do i=1,j c call add2s2(w,v(1,i),-wk1(i),ntot2)! w = w - h v c h(i,j) = h(i,j) + wk1(i) ! i,j i c enddo !apply Givens rotations to new column do i=1,j-1 temp = h(i,j) h(i ,j)= c(i)*temp + s(i)*h(i+1,j) h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) enddo ! ______ alpha = sqrt(glsc2(w,w,ntot2)) ! alpha = \/ (w,w) rnorm = 0. if(alpha.eq.0.) goto 900 !converged l = sqrt(h(j,j)*h(j,j)+alpha*alpha) temp = 1./l c(j) = h(j,j) * temp s(j) = alpha * temp h(j,j) = l gamma(j+1) = -s(j) * gamma(j) gamma(j) = c(j) * gamma(j) c call outmat(h,m,j,' h ',j) rnorm = abs(gamma(j+1))*norm_fac ratio = rnorm/div0 if (ifprint.and.nid.eq.0) $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep 66 format(i5,1p4e12.5,i8,' Divergence') #ifndef TST_WSCAL if (rnorm .lt. tolpss) goto 900 !converged #else if (iter.gt.param(151)-1) goto 900 #endif if (j.eq.m) goto 1000 !not converged, restart temp = 1./alpha call cmult2(v(1,j+1),w,temp,ntot2) ! v = w / alpha ! j+1 enddo 900 iconv = 1 1000 continue !back substitution ! -1 !c = H gamma do k=j,1,-1 temp = gamma(k) do i=j,k+1,-1 temp = temp - h(k,i)*c(i) enddo c(k) = temp/h(k,k) enddo !sum up Arnoldi vectors do i=1,j call add2s2(x,z(1,i),c(i),ntot2) ! x = x + c z ! i i enddo c if(iconv.eq.1) call dbg_write(x,nx2,ny2,nz2,nelv,'esol',3) enddo 9000 continue c divex = rnorm c iter = iter - 1 c c DIAGNOSTICS c call copy(w,x,ntot2) c if (ifvcor) then c xaver = glsc2(bm2,w,ntot2)/volvm2 c call cadd(w,-xaver,ntot2) c endif c call copy(r,res,ntot2) !r = res c call cdabdtp(r,w,h1,h2,h2inv,intype) ! r = A w c do i=1,ntot2 c r(i) = res(i) - r(i) ! r = res - r c enddo c call uzawa_gmres_temp(r,bm2inv,ntot2) c ! ______ c gamma(1) = sqrt(glsc2(r,r,ntot2)/volvm2) ! gamma = \/ (r,r) c ! 1 c print *, 'GMRES end resid:',gamma(1) c END DIAGNOSTICS call copy(res,x,ntot2) c if (ifvcor) then xaver = glsc2(bm2,res,ntot2)/volvm2 call cadd(res,-xaver,ntot2) endif c etime1 = dnekclock()-etime1 if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, & etime1 c call flush_hack 9999 format(4X,I7,' U-Pres gmres: ',I6,1p5E13.4) c c return end c----------------------------------------------------------------------- subroutine uzawa_gmres_split0(l,u,b,binv,n) integer n real l(n),u(n),b(n),binv(n) integer i do i=1,n l(i)=sqrt(binv(i)) u(i)=sqrt(b(i)) if(abs(u(i)*l(i)-1.0).gt.1e-13) print *, i, u(i)*l(i) enddo return end c----------------------------------------------------------------------- subroutine uzawa_gmres_split(l,u,b,binv,n) integer n real l(n),u(n),b(n),binv(n) integer i do i=1,n c l(i)=sqrt(binv(i)) c u(i)=sqrt(b(i)) c u(i)=sqrt(b(i)) c l(i)=1./u(i) c l(i)=sqrt(binv(i)) l(i)=1. u(i)=1./l(i) c if(abs(u(i)*l(i)-1.0).gt.1e-13)write(6,*) i,u(i)*l(i),' gmr_sp' enddo return end c----------------------------------------------------------------------- subroutine uzawa_gmres_temp(a,b,n) integer n real a(n),b(n) integer i do i=1,n a(i)=sqrt(b(i))*a(i) enddo return end c----------------------------------------------------------------------- subroutine ax(w,x,h1,h2,n) include 'SIZE' include 'TOTAL' c c w = A*x for pressure iteration c integer n real w(n),x(n),h1(n),h2(n) imsh = 1 isd = 1 call axhelm (w,x,h1,h2,imsh,isd) call dssum (w,nx1,ny1,nz1) call col2 (w,pmask,n) return end c----------------------------------------------------------------------- subroutine hmh_gmres(res,h1,h2,wt,iter) c Solve the Helmholtz equation by right-preconditioned c GMRES iteration. include 'SIZE' include 'TOTAL' include 'FDMH1' include 'GMRES' common /ctolpr/ divex common /cprint/ ifprint logical ifprint real res (lx1*ly1*lz1*lelv) real h1 (lx1,ly1,lz1,lelv) real h2 (lx1,ly1,lz1,lelv) real wt (lx1,ly1,lz1,lelv) common /scrcg/ d(lx1*ly1*lz1*lelv),wk(lx1*ly1*lz1*lelv) common /cgmres1/ y(lgmres) common /ctmp0/ wk1(lgmres),wk2(lgmres) real alpha, l, temp integer j,m logical iflag save iflag data iflag /.false./ real norm_fac save norm_fac real*8 etime1,dnekclock n = nx1*ny1*nz1*nelv etime1 = dnekclock() etime_p = 0. divex = 0. iter = 0 m = lgmres if(.not.iflag) then iflag=.true. call uzawa_gmres_split(ml,mu,bm1,binvm1,nx1*ny1*nz1*nelv) norm_fac = 1./sqrt(volvm1) endif call set_fdm_prec_h1b(d,h1,h2,nelv) if (ifvcor) smean = -1./glsum(vmult,n) call chktcg1(tolps,res,h1,h2,pmask,vmult,1,1) if (param(21).gt.0.and.tolps.gt.abs(param(21))) $ tolps = abs(param(21)) if (istep.eq.0) tolps = 1.e-4 tolpss = tolps c iconv = 0 call rzero(x,n) do while(iconv.eq.0.and.iter.lt.500) if(iter.eq.0) then ! -1 call col3(r,ml,res,n) ! r = L res c call copy(r,res,n) else !update residual call copy (r,res,n) ! r = res call ax (w,x,h1,h2,n) ! w = A x call add2s2(r,w,-1.,n) ! r = r - w ! -1 call col2(r,ml,n) ! r = L r endif ! ______ gamma(1) = sqrt(glsc3(r,r,wt,n)) ! gamma = \/ (r,r) ! 1 if(iter.eq.0) then div0 = gamma(1)*norm_fac if (param(21).lt.0) tolpss=abs(param(21))*div0 endif !check for lucky convergence rnorm = 0. if(gamma(1) .eq. 0.) goto 9000 temp = 1./gamma(1) call cmult2(v(1,1),r,temp,n) ! v = r / gamma ! 1 1 do j=1,m iter = iter+1 ! -1 call col3(w,mu,v(1,j),n) ! w = U v ! j c . . . . . Overlapping Schwarz + coarse-grid . . . . . . . etime2 = dnekclock() kfldfdm = ndim+1 call fdm_h1 $ (z(1,j),w,d,pmask,vmult,nelv,ktype(1,1,kfldfdm),wk) call crs_solve_h1 (wk,w) c call hsmg_solve(z(1,j),w) ! z = M w ! j call add2 (z(1,j),wk,n) if (ifvcor) then rmean = smean*glsc2(z(1,j),vmult,n) call cadd(z(1,j),rmean,n) endif etime_p = etime_p + dnekclock()-etime2 c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . call ax (w,z(1,j),h1,h2,n) ! w = A z ! j ! -1 call col2(w,ml,n) ! w = L w c !modified Gram-Schmidt c do i=1,j c h(i,j)=glsc3(w,v(1,i),wt,n) ! h = (w,v ) c ! i,j i c call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v c enddo ! i,j i c 2-PASS GS, 1st pass: do i=1,j h(i,j)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) enddo ! i,j i call gop(h(1,j),wk1,'+ ',j) ! sum over P procs do i=1,j call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v enddo ! i,j i c 2-PASS GS, 2nd pass: c c do i=1,j c wk1(i)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) c enddo ! i,j i c ! c call gop(wk1,wk2,'+ ',j) ! sum over P procs c c do i=1,j c call add2s2(w,v(1,i),-wk1(i),n) ! w = w - h v c h(i,j) = h(i,j) + wk1(i) ! i,j i c enddo !apply Givens rotations to new column do i=1,j-1 temp = h(i,j) h(i ,j)= c(i)*temp + s(i)*h(i+1,j) h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) enddo ! ______ alpha = sqrt(glsc3(w,w,wt,n)) ! alpha = \/ (w,w) rnorm = 0. if(alpha.eq.0.) goto 900 !converged l = sqrt(h(j,j)*h(j,j)+alpha*alpha) temp = 1./l c(j) = h(j,j) * temp s(j) = alpha * temp h(j,j) = l gamma(j+1) = -s(j) * gamma(j) gamma(j) = c(j) * gamma(j) rnorm = abs(gamma(j+1))*norm_fac ratio = rnorm/div0 if (ifprint.and.nid.eq.0) $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep 66 format(i5,1p4e12.5,i8,' Divergence') #ifndef TST_WSCAL if (rnorm .lt. tolpss) goto 900 !converged #else if (iter.gt.param(151)-1) goto 900 #endif if (j.eq.m) goto 1000 !not converged, restart temp = 1./alpha call cmult2(v(1,j+1),w,temp,n) ! v = w / alpha ! j+1 enddo 900 iconv = 1 1000 continue !back substitution ! -1 !c = H gamma do k=j,1,-1 temp = gamma(k) do i=j,k+1,-1 temp = temp - h(k,i)*c(i) enddo c(k) = temp/h(k,k) enddo !sum up Arnoldi vectors do i=1,j call add2s2(x,z(1,i),c(i),n) ! x = x + c z enddo ! i i c if(iconv.eq.1) call dbg_write(x,nx1,ny1,nz1,nelv,'esol',3) enddo 9000 continue c divex = rnorm call copy(res,x,n) c if (ifvcor) then xaver = glsc2(bm1,res,n)/volvm1 call cadd(res,-xaver,n) endif c etime1 = dnekclock()-etime1 if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, & etime1 c call flush_hack 9999 format(4X,I7,' PRES gmres: ',I6,1p5E13.4) return end c----------------------------------------------------------------------- From nek5000-users at lists.mcs.anl.gov Wed Apr 21 09:36:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 16:36:41 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: References: <1271851086.31181.46.camel@localhost.localdomain> <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> Message-ID: <1271860601.31181.62.camel@localhost.localdomain> On Wed, 2010-04-21 at 14:25 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Ok I think what happens is the following: > > We need to detect which compilers are used by the MPI-wrappers. Depending on the MPI implementation there are some flags (e.g. -showme / -show) you can use to figure that out. > > MPICH doesn't know the flag -showme hence it is passed to the compiler (in your case sunf95). > The sun compiler says this is an unknown flag and returns a ZERO exit code. > This is weird if not to say wrong because you would assume that the right exit code should be NON-ZERO in this case! > > It looks like only the SUN compiler behaves wrong in this situation. > Unfortunately I don't have access to machine with MPICH/SUN so I cannot test my hypothesis. Hi Stefan, I have made an account for you on a workstation here with the Sun compiler. The various Mpichs are in /usr/local/progams. Currently mpif77 points to the mpich using the Sun compiler. login: stefan pass: dnsnek5000 Perhaps one could get the compiler name from the mpif77 script: [fmuldoo at tetra programs]# grep 'FC="ifort"' mpif77 FC="ifort" Cheers, Frank > > Stefan > > > On Apr 21, 2010, at 2:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > What MPI implementation are you using? > > > > Stefan > > > > > > On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Hello all, > >> > >> I am seeing the following error message when I use an mpif77 and mpicc > >> that use the Sun compilers. Everything is fine if in makenek F77=sunf95 > >> and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use > >> the Intel compilers. > >> > >> Cheers, > >> Frank > >> > >> > >> sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored > >> otherwise > >> Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details > >> WARNING: Cannot detect compiler specfic flags > >> echo - to promote REAL to 8 bytes > >> echo - to invoke preprocessor first > >> Please edit the makefile and specify the requested compiler flags in the > >> P variable! > >> > >> -- > >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >> Technische Universit?t Wien (Technical University of Vienna) > >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >> Mechanics and Heat Transfer) > >> Resselgasse 3 > >> 1040 Wien > >> Tel: +4315880132232 > >> Fax: +4315880132299 > >> Cell:+436765203470 > >> fmuldoo (skype) > >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 21 09:40:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 16:40:38 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: <1271860601.31181.62.camel@localhost.localdomain> References: <1271851086.31181.46.camel@localhost.localdomain> <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> <1271860601.31181.62.camel@localhost.localdomain> Message-ID: <2B4F00D0-AD60-4470-A1E4-FE4CE037A7DB@lav.mavt.ethz.ch> Ups, please change the passwd immediately. This is a public mailing list! Just send the new passwd to my private email address or via skype (ask for my username in your email). Thx Steafn On Apr 21, 2010, at 4:36 PM, nek5000-users at lists.mcs.anl.gov wrote: > On Wed, 2010-04-21 at 14:25 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Ok I think what happens is the following: >> >> We need to detect which compilers are used by the MPI-wrappers. Depending on the MPI implementation there are some flags (e.g. -showme / -show) you can use to figure that out. >> >> MPICH doesn't know the flag -showme hence it is passed to the compiler (in your case sunf95). >> The sun compiler says this is an unknown flag and returns a ZERO exit code. >> This is weird if not to say wrong because you would assume that the right exit code should be NON-ZERO in this case! >> >> It looks like only the SUN compiler behaves wrong in this situation. >> Unfortunately I don't have access to machine with MPICH/SUN so I cannot test my hypothesis. > > Hi Stefan, > > I have made an account for you on a workstation here with the Sun > compiler. The various Mpichs are in /usr/local/progams. Currently > mpif77 points to the mpich using the Sun compiler. > > login: stefan > pass: dnsnek5000 > > Perhaps one could get the compiler name from the mpif77 script: > > [fmuldoo at tetra programs]# grep 'FC="ifort"' mpif77 > FC="ifort" > > Cheers, > Frank > >> >> Stefan >> >> >> On Apr 21, 2010, at 2:00 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> What MPI implementation are you using? >>> >>> Stefan >>> >>> >>> On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello all, >>>> >>>> I am seeing the following error message when I use an mpif77 and mpicc >>>> that use the Sun compilers. Everything is fine if in makenek F77=sunf95 >>>> and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use >>>> the Intel compilers. >>>> >>>> Cheers, >>>> Frank >>>> >>>> >>>> sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored >>>> otherwise >>>> Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details >>>> WARNING: Cannot detect compiler specfic flags >>>> echo - to promote REAL to 8 bytes >>>> echo - to invoke preprocessor first >>>> Please edit the makefile and specify the requested compiler flags in the >>>> P variable! >>>> >>>> -- >>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>> Technische Universit?t Wien (Technical University of Vienna) >>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>> Mechanics and Heat Transfer) >>>> Resselgasse 3 >>>> 1040 Wien >>>> Tel: +4315880132232 >>>> Fax: +4315880132299 >>>> Cell:+436765203470 >>>> fmuldoo (skype) >>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 09:56:36 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 09:56:36 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <353290148.10238991271861787455.JavaMail.root@neo-mail-3> Message-ID: <1969211421.10239111271861796278.JavaMail.root@neo-mail-3> Hi, I just generated a coarser mesh and am getting the same error messages. This one may be easier to figure out though with fewer elements. Regards, Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, April 21, 2010 9:19:46 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Vanishing Jacobian error description Hi, Sorry, yes that was for without the curve side data. Here is the case that includes the curved side data. - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, April 21, 2010 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Vanishing Jacobian error description The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > 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, nek5000-users at lists.mcs.anl.gov 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 > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test3.tar Type: application/x-tar Size: 4935 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 10:00:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 10:00:29 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <679557729.10223601271859586450.JavaMail.root@neo-mail-3> References: <679557729.10223601271859586450.JavaMail.root@neo-mail-3> Message-ID: Michael, I looked at this for a couple of different N. nek/postx think that the geometry is messed up --- see www.mcs.anl.gov/~fischer/zzz.jpg That being said, it could easily be a problem w/ the midside node support that I added last month. (NOTE: to see the geometry I had to fix something in the nek code -- normally when you get vanishing jacobian the code will output "xyzblah.fld01" with the geometry, so that you can then look at this in postx or visit. For pn/pn, this was broken but is now working in the just-updated repo.) Do you have a way to verify that your lofting is working? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Sorry, yes that was for without the curve side data. Here is the case that includes the curved side data. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 U S/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, nek5000-users at lists.mcs.anl.gov 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+0 0 >> 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 > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 10:02:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 10:02:16 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: References: <679557729.10223601271859586450.JavaMail.root@neo-mail-3> Message-ID: One other question - Have you sorted out how the 12 edges are numbered? On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > Michael, > > I looked at this for a couple of different N. > > nek/postx think that the geometry is messed up --- > > see www.mcs.anl.gov/~fischer/zzz.jpg > > That being said, it could easily be a problem w/ the midside > node support that I added last month. (NOTE: to see the > geometry I had to fix something in the nek code -- normally > when you get vanishing jacobian the code will output "xyzblah.fld01" > with the geometry, so that you can then look at this in postx or > visit. For pn/pn, this was broken but is now working in the just-updated > repo.) > > Do you have a way to verify that your lofting is working? > > Paul > > > On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> Sorry, yes that was for without the curve side data. Here is the case that >> includes the curved side data. >> >> - Michael >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Wednesday, April 21, 2010 8:39:38 AM GMT -06:00 Guadalajara / Mexico >> City / Monterrey >> Subject: Re: [Nek5000-users] Vanishing Jacobian error description >> >> The case you sent runs fine.... is it w/ or w/o the curved side info? Paul >> On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: >> nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, >> April 20, 2010 3:36:44 PM GMT -06:00 U > S/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, > nek5000-users at lists.mcs.anl.gov 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+0 > 0 >> 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 >> Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> _______________________________________________ Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 09:07:18 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 10:07:18 -0400 Subject: [Nek5000-users] Residuals for post-processing In-Reply-To: References: <4BCEF889.1050105@vt.edu> Message-ID: <4BCF0696.7080905@vt.edu> Hi, thank you, calling it after the time step is what I need. There is a backward facing step within my domain. In order to shorten reattachment length, we tried to apply suction at the backward facing wall (using a velocity boundary condition with negative (opposing the mean flow direction) velocity magnitude). Doing initial testing with PN/PN-2, this seems to work for lower polynomial orders, but as soon as I up lx1 (from 6 to 8, say), gmres will not decrease over iterations but remain at a constant level (this level becoming higher with lx1 increasing further). I tried to decrease dt, but that doesn't help. So I wanted to see if high pressure residuals are really in that area of the suction slot or if the problem is somewhere else. Thanks again, Markus nek5000-users at lists.mcs.anl.gov wrote: > > Hi Markus, > > pressure residuals are in gmres > > You could output them via: > > call outpost(x,y,z,res,t,'res') > > where x,y,z,t are arrays of your choice and res > is the array you want to look at. > > Nek will convert the res mesh to the velocity mesh > if needed. I usually follow such a call with > > call exitti('quit in gmres$',n) > > because prepost() uses some scratch common blocks > that are potentially shared with the calling routine > (not in the case of gmres, I think...) -- so data might be corrupted > after such a call. The idea of > prepost was to be called in between timesteps, when > such memory re-use would be admissable. The alternative > would be to define your own storage in a common block, > save the residuals to this locale, then loop through > calls to outpost in userchk afterwards... I've done > that in the past. > > All this being said, I'm not 100% certain that the > iterative solvers is the place to look for the difficulty. > Most problems arise from spatial resolution issues...or > temporal stability problems. The latter can be identified > by drastic reduction in dt. > > What exactly is blowing up for you? > > Paul > > > On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> I'd like to save the residuals for the pressure iterations (PN/PN-2 as >> well as PN/PN) into a scalar variable (scalar 0, instead of >> temperature say) for each grid point in order to see where my solution >> diverges. >> Is there a way to add something to the .usr file to do that? I >> couldn't find the variable in the code and also wouldn't know how to >> save something from the lx2=lx1-2 grid onto the lx1 grid. >> Would this also be possible with the velocity residuals? >> >> Thanks, >> Markus >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > uuuu > c----------------------------------------------------------------------- > subroutine uzawa_gmres(res,h1,h2,h2inv,intype,iter) > > c Solve the pressure equation by right-preconditioned c GMRES > iteration. > c intype = 0 (steady) > c intype = 1 (explicit) > c intype = -1 (implicit) > > include 'SIZE' > include 'TOTAL' > include 'GMRES' > common /ctolpr/ divex > common /cprint/ ifprint > logical ifprint > real res (lx2*ly2*lz2*lelv) > real h1 (lx1,ly1,lz1,lelv) > real h2 (lx1,ly1,lz1,lelv) > real h2inv(lx1,ly1,lz1,lelv) > > common /scrmg/ wp (lx2,ly2,lz2,lelv) > > common /ctmp0/ wk1(lgmres),wk2(lgmres) > common /cgmres1/ y(lgmres) > > real alpha, l, temp > integer j,m > c > logical iflag > save iflag > data iflag /.false./ > real norm_fac > save norm_fac > c > real*8 etime1,dnekclock > c > if(.not.iflag) then > iflag=.true. > call uzawa_gmres_split0(ml,mu,bm2,bm2inv,nx2*ny2*nz2*nelv) > norm_fac = 1./sqrt(volvm2) > endif > c > etime1 = dnekclock() > etime_p = 0. > divex = 0. > iter = 0 > m = lgmres > c > call chktcg2(tolps,res,iconv) > if (param(21).gt.0.and.tolps.gt.abs(param(21))) > $ tolps = abs(param(21)) > c if (param(21).lt.0) tolps = abs(param(21)) > if (istep.eq.0) tolps = 1.e-4 > tolpss = tolps > c > ntot2 = nx2*ny2*nz2*nelv > c > iconv = 0 > call rzero(x,ntot2) > > do while(iconv.eq.0.and.iter.lt.100) > > if(iter.eq.0) then > ! -1 > call col3(r,ml,res,ntot2) ! r = L res > c call copy(r,res,ntot2) > else > !update residual > call copy(r,res,ntot2) ! r = res > call cdabdtp(w,x,h1,h2,h2inv,intype) ! w = A x > call add2s2(r,w,-1.,ntot2) ! r = r - w > ! -1 > call col2(r,ml,ntot2) ! r = L r > endif > ! ______ > gamma(1) = sqrt(glsc2(r,r,ntot2)) ! gamma = \/ (r,r) > ! 1 > if(iter.eq.0) then > div0 = gamma(1)*norm_fac > if (param(21).lt.0) tolpss=abs(param(21))*div0 > endif > > !check for lucky convergence > rnorm = 0. > if(gamma(1) .eq. 0.) goto 9000 > temp = 1./gamma(1) > call cmult2(v(1,1),r,temp,ntot2) ! v = r / gamma > ! 1 1 > do j=1,m > iter = iter+1 > ! -1 > call col3(w,mu,v(1,j),ntot2) ! w = U v > ! j > > etime2 = dnekclock() > if(param(43).eq.1) then > call uzprec(z(1,j),w,h1,h2,intype,wp) > else ! -1 > call hsmg_solve(z(1,j),w) ! z = M w > endif > etime_p = etime_p + dnekclock()-etime2 > > call cdabdtp(w,z(1,j), ! w = A z > $ h1,h2,h2inv,intype) ! j > > ! -1 > call col2(w,ml,ntot2) ! w = L w > > c !modified Gram-Schmidt > c do i=1,j > c h(i,j)=glsc2(w,v(1,i),ntot2) ! h = (w,v ) > c ! i,j i > c call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v > c enddo ! i,j i > > > c 2-PASS GS, 1st pass: > > do i=1,j > h(i,j)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) > enddo ! i,j i > > call gop(h(1,j),wk1,'+ ',j) ! sum over P procs > > do i=1,j > call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v > enddo ! i,j i > > > c 2-PASS GS, 2nd pass: > c > c do i=1,j > c wk1(i)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) > c enddo ! i,j i > c ! > c call gop(wk1,wk2,'+ ',j) ! sum over P procs > c > c do i=1,j > c call add2s2(w,v(1,i),-wk1(i),ntot2)! w = w - h v > c h(i,j) = h(i,j) + wk1(i) ! i,j i > c enddo > > > !apply Givens rotations to new column > do i=1,j-1 > temp = h(i,j) > h(i ,j)= c(i)*temp + s(i)*h(i+1,j) > h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) > enddo > ! ______ > alpha = sqrt(glsc2(w,w,ntot2)) ! alpha = \/ (w,w) > rnorm = 0. > if(alpha.eq.0.) goto 900 !converged > l = sqrt(h(j,j)*h(j,j)+alpha*alpha) > temp = 1./l > c(j) = h(j,j) * temp > s(j) = alpha * temp > h(j,j) = l > gamma(j+1) = -s(j) * gamma(j) > gamma(j) = c(j) * gamma(j) > > c call outmat(h,m,j,' h ',j) > > rnorm = abs(gamma(j+1))*norm_fac > ratio = rnorm/div0 > if (ifprint.and.nid.eq.0) > $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep > 66 format(i5,1p4e12.5,i8,' Divergence') > > #ifndef TST_WSCAL > if (rnorm .lt. tolpss) goto 900 !converged > #else > if (iter.gt.param(151)-1) goto 900 > #endif > if (j.eq.m) goto 1000 !not converged, restart > > temp = 1./alpha > call cmult2(v(1,j+1),w,temp,ntot2) ! v = w / alpha > ! j+1 > enddo > 900 iconv = 1 > 1000 continue > !back substitution > ! -1 > !c = H gamma > do k=j,1,-1 > temp = gamma(k) > do i=j,k+1,-1 > temp = temp - h(k,i)*c(i) > enddo > c(k) = temp/h(k,k) > enddo > !sum up Arnoldi vectors > do i=1,j > call add2s2(x,z(1,i),c(i),ntot2) ! x = x + c z > ! i i > enddo > c if(iconv.eq.1) call dbg_write(x,nx2,ny2,nz2,nelv,'esol',3) > enddo > 9000 continue > c > divex = rnorm > c iter = iter - 1 > c > c DIAGNOSTICS > c call copy(w,x,ntot2) > c if (ifvcor) then > c xaver = glsc2(bm2,w,ntot2)/volvm2 > c call cadd(w,-xaver,ntot2) > c endif > c call copy(r,res,ntot2) !r = res > c call cdabdtp(r,w,h1,h2,h2inv,intype) ! r = A w > c do i=1,ntot2 > c r(i) = res(i) - r(i) ! r = res - r > c enddo > c call uzawa_gmres_temp(r,bm2inv,ntot2) > c ! ______ > c gamma(1) = sqrt(glsc2(r,r,ntot2)/volvm2) ! gamma = \/ (r,r) > c ! 1 > c print *, 'GMRES end resid:',gamma(1) > c END DIAGNOSTICS > call copy(res,x,ntot2) > c > if (ifvcor) then > xaver = glsc2(bm2,res,ntot2)/volvm2 > call cadd(res,-xaver,ntot2) > endif > c > etime1 = dnekclock()-etime1 > if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, > & etime1 > c call flush_hack > 9999 format(4X,I7,' U-Pres gmres: ',I6,1p5E13.4) > c > c > return > end > > c----------------------------------------------------------------------- > > subroutine uzawa_gmres_split0(l,u,b,binv,n) > integer n > real l(n),u(n),b(n),binv(n) > integer i > do i=1,n > l(i)=sqrt(binv(i)) > u(i)=sqrt(b(i)) > if(abs(u(i)*l(i)-1.0).gt.1e-13) print *, i, u(i)*l(i) > enddo > return > end > > c----------------------------------------------------------------------- > subroutine uzawa_gmres_split(l,u,b,binv,n) > integer n > real l(n),u(n),b(n),binv(n) > integer i > do i=1,n > c l(i)=sqrt(binv(i)) > c u(i)=sqrt(b(i)) > > c u(i)=sqrt(b(i)) > c l(i)=1./u(i) > > c l(i)=sqrt(binv(i)) > l(i)=1. > u(i)=1./l(i) > > > c if(abs(u(i)*l(i)-1.0).gt.1e-13)write(6,*) i,u(i)*l(i),' gmr_sp' > enddo > return > end > > c----------------------------------------------------------------------- > subroutine uzawa_gmres_temp(a,b,n) > integer n > real a(n),b(n) > integer i > do i=1,n > a(i)=sqrt(b(i))*a(i) > enddo > return > end > c----------------------------------------------------------------------- > subroutine ax(w,x,h1,h2,n) > include 'SIZE' > include 'TOTAL' > > c > c w = A*x for pressure iteration > c > > integer n > real w(n),x(n),h1(n),h2(n) > > imsh = 1 > isd = 1 > call axhelm (w,x,h1,h2,imsh,isd) > call dssum (w,nx1,ny1,nz1) > call col2 (w,pmask,n) > > return > end > c----------------------------------------------------------------------- > subroutine hmh_gmres(res,h1,h2,wt,iter) > > c Solve the Helmholtz equation by right-preconditioned c GMRES > iteration. > > > include 'SIZE' > include 'TOTAL' > include 'FDMH1' > include 'GMRES' > common /ctolpr/ divex > common /cprint/ ifprint > logical ifprint > real res (lx1*ly1*lz1*lelv) > real h1 (lx1,ly1,lz1,lelv) > real h2 (lx1,ly1,lz1,lelv) > real wt (lx1,ly1,lz1,lelv) > > common /scrcg/ d(lx1*ly1*lz1*lelv),wk(lx1*ly1*lz1*lelv) > > common /cgmres1/ y(lgmres) > common /ctmp0/ wk1(lgmres),wk2(lgmres) > real alpha, l, temp > integer j,m > > logical iflag > save iflag > data iflag /.false./ > real norm_fac > save norm_fac > > real*8 etime1,dnekclock > > > n = nx1*ny1*nz1*nelv > > etime1 = dnekclock() > etime_p = 0. > divex = 0. > iter = 0 > m = lgmres > > if(.not.iflag) then > iflag=.true. > call uzawa_gmres_split(ml,mu,bm1,binvm1,nx1*ny1*nz1*nelv) > norm_fac = 1./sqrt(volvm1) > endif > > call set_fdm_prec_h1b(d,h1,h2,nelv) > if (ifvcor) smean = -1./glsum(vmult,n) > > call chktcg1(tolps,res,h1,h2,pmask,vmult,1,1) > if (param(21).gt.0.and.tolps.gt.abs(param(21))) > $ tolps = abs(param(21)) > if (istep.eq.0) tolps = 1.e-4 > tolpss = tolps > c > iconv = 0 > call rzero(x,n) > > do while(iconv.eq.0.and.iter.lt.500) > > if(iter.eq.0) then ! -1 > call col3(r,ml,res,n) ! r = L res > c call copy(r,res,n) > else > !update residual > call copy (r,res,n) ! r = res > call ax (w,x,h1,h2,n) ! w = A x > call add2s2(r,w,-1.,n) ! r = r - w > ! -1 > call col2(r,ml,n) ! r = L r > endif > ! ______ > gamma(1) = sqrt(glsc3(r,r,wt,n)) ! gamma = \/ (r,r) > ! 1 > if(iter.eq.0) then > div0 = gamma(1)*norm_fac > if (param(21).lt.0) tolpss=abs(param(21))*div0 > endif > > !check for lucky convergence > rnorm = 0. > if(gamma(1) .eq. 0.) goto 9000 > temp = 1./gamma(1) > call cmult2(v(1,1),r,temp,n) ! v = r / gamma > ! 1 1 > do j=1,m > iter = iter+1 > ! -1 > call col3(w,mu,v(1,j),n) ! w = U v > ! j > > c . . . . . Overlapping Schwarz + coarse-grid . . . . . . . > > etime2 = dnekclock() > kfldfdm = ndim+1 > call fdm_h1 > $ (z(1,j),w,d,pmask,vmult,nelv,ktype(1,1,kfldfdm),wk) > call crs_solve_h1 (wk,w) c call > hsmg_solve(z(1,j),w) ! z = M w > ! j > call add2 (z(1,j),wk,n) > if (ifvcor) then > rmean = smean*glsc2(z(1,j),vmult,n) > call cadd(z(1,j),rmean,n) > endif > etime_p = etime_p + dnekclock()-etime2 > c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > > > call ax (w,z(1,j),h1,h2,n) ! w = A z > ! j > > ! -1 > call col2(w,ml,n) ! w = L w > > c !modified Gram-Schmidt > > c do i=1,j > c h(i,j)=glsc3(w,v(1,i),wt,n) ! h = (w,v ) > c ! i,j i > > c call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v > c enddo ! i,j i > > c 2-PASS GS, 1st pass: > > do i=1,j > h(i,j)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) > enddo ! i,j i > > call gop(h(1,j),wk1,'+ ',j) ! sum over P procs > > do i=1,j > call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v > enddo ! i,j i > > > c 2-PASS GS, 2nd pass: > c > c do i=1,j > c wk1(i)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) > c enddo ! i,j i > c ! > c call gop(wk1,wk2,'+ ',j) ! sum over P procs > c > c do i=1,j > c call add2s2(w,v(1,i),-wk1(i),n) ! w = w - h v > c h(i,j) = h(i,j) + wk1(i) ! i,j i > c enddo > > !apply Givens rotations to new column > do i=1,j-1 > temp = h(i,j) > h(i ,j)= c(i)*temp + s(i)*h(i+1,j) > h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) > enddo > ! ______ > alpha = sqrt(glsc3(w,w,wt,n)) ! alpha = \/ (w,w) > rnorm = 0. > if(alpha.eq.0.) goto 900 !converged > l = sqrt(h(j,j)*h(j,j)+alpha*alpha) > temp = 1./l > c(j) = h(j,j) * temp > s(j) = alpha * temp > h(j,j) = l > gamma(j+1) = -s(j) * gamma(j) > gamma(j) = c(j) * gamma(j) > > rnorm = abs(gamma(j+1))*norm_fac > ratio = rnorm/div0 > if (ifprint.and.nid.eq.0) > $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep > 66 format(i5,1p4e12.5,i8,' Divergence') > > #ifndef TST_WSCAL > if (rnorm .lt. tolpss) goto 900 !converged > #else > if (iter.gt.param(151)-1) goto 900 > #endif > if (j.eq.m) goto 1000 !not converged, restart > > temp = 1./alpha > call cmult2(v(1,j+1),w,temp,n) ! v = w / alpha > ! j+1 > enddo > 900 iconv = 1 > 1000 continue > !back substitution > ! -1 > !c = H gamma > do k=j,1,-1 > temp = gamma(k) > do i=j,k+1,-1 > temp = temp - h(k,i)*c(i) > enddo > c(k) = temp/h(k,k) > enddo > !sum up Arnoldi vectors > do i=1,j > call add2s2(x,z(1,i),c(i),n) ! x = x + c z > enddo ! i i > c if(iconv.eq.1) call dbg_write(x,nx1,ny1,nz1,nelv,'esol',3) > enddo > 9000 continue > c > divex = rnorm > call copy(res,x,n) > c > if (ifvcor) then > xaver = glsc2(bm1,res,n)/volvm1 > call cadd(res,-xaver,n) > endif > c > etime1 = dnekclock()-etime1 > if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, > & etime1 > c call flush_hack > 9999 format(4X,I7,' PRES gmres: ',I6,1p5E13.4) > > return > end > c----------------------------------------------------------------------- > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Apr 21 10:06:42 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 10:06:42 -0500 (CDT) Subject: [Nek5000-users] Residuals for post-processing In-Reply-To: <4BCF0696.7080905@vt.edu> References: <4BCEF889.1050105@vt.edu> <4BCF0696.7080905@vt.edu> Message-ID: Do you end up sucking any flow into the outflow ? If so, the std fix for that is to set div U > 0 near the outflow... Typically I find it sufficient to dump at every step over the last few steps prior to blow up to identify the problem... hth Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > thank you, calling it after the time step is what I need. > > There is a backward facing step within my domain. In order to shorten > reattachment length, we tried to apply suction at the backward facing wall > (using a velocity boundary condition with negative (opposing the mean flow > direction) velocity magnitude). > Doing initial testing with PN/PN-2, this seems to work for lower polynomial > orders, but as soon as I up lx1 (from 6 to 8, say), gmres will not decrease > over iterations but remain at a constant level (this level becoming higher > with lx1 increasing further). > I tried to decrease dt, but that doesn't help. So I wanted to see if high > pressure residuals are really in that area of the suction slot or if the > problem is somewhere else. > > Thanks again, > Markus > > > nek5000-users at lists.mcs.anl.gov wrote: >> >> Hi Markus, >> >> pressure residuals are in gmres >> >> You could output them via: >> >> call outpost(x,y,z,res,t,'res') >> >> where x,y,z,t are arrays of your choice and res >> is the array you want to look at. >> >> Nek will convert the res mesh to the velocity mesh >> if needed. I usually follow such a call with >> >> call exitti('quit in gmres$',n) >> >> because prepost() uses some scratch common blocks >> that are potentially shared with the calling routine >> (not in the case of gmres, I think...) -- so data might be corrupted after >> such a call. The idea of >> prepost was to be called in between timesteps, when >> such memory re-use would be admissable. The alternative >> would be to define your own storage in a common block, >> save the residuals to this locale, then loop through >> calls to outpost in userchk afterwards... I've done >> that in the past. >> >> All this being said, I'm not 100% certain that the >> iterative solvers is the place to look for the difficulty. >> Most problems arise from spatial resolution issues...or >> temporal stability problems. The latter can be identified >> by drastic reduction in dt. >> >> What exactly is blowing up for you? >> >> Paul >> >> >> On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> I'd like to save the residuals for the pressure iterations (PN/PN-2 as >>> well as PN/PN) into a scalar variable (scalar 0, instead of temperature >>> say) for each grid point in order to see where my solution diverges. >>> Is there a way to add something to the .usr file to do that? I couldn't >>> find the variable in the code and also wouldn't know how to save something >>> from the lx2=lx1-2 grid onto the lx1 grid. >>> Would this also be possible with the velocity residuals? >>> >>> Thanks, >>> Markus >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> uuuu >> c----------------------------------------------------------------------- >> subroutine uzawa_gmres(res,h1,h2,h2inv,intype,iter) >> >> c Solve the pressure equation by right-preconditioned c GMRES >> iteration. >> c intype = 0 (steady) >> c intype = 1 (explicit) >> c intype = -1 (implicit) >> >> include 'SIZE' >> include 'TOTAL' >> include 'GMRES' >> common /ctolpr/ divex >> common /cprint/ ifprint >> logical ifprint >> real res (lx2*ly2*lz2*lelv) >> real h1 (lx1,ly1,lz1,lelv) >> real h2 (lx1,ly1,lz1,lelv) >> real h2inv(lx1,ly1,lz1,lelv) >> >> common /scrmg/ wp (lx2,ly2,lz2,lelv) >> >> common /ctmp0/ wk1(lgmres),wk2(lgmres) >> common /cgmres1/ y(lgmres) >> >> real alpha, l, temp >> integer j,m >> c >> logical iflag >> save iflag >> data iflag /.false./ >> real norm_fac >> save norm_fac >> c >> real*8 etime1,dnekclock >> c >> if(.not.iflag) then >> iflag=.true. >> call uzawa_gmres_split0(ml,mu,bm2,bm2inv,nx2*ny2*nz2*nelv) >> norm_fac = 1./sqrt(volvm2) >> endif >> c >> etime1 = dnekclock() >> etime_p = 0. >> divex = 0. >> iter = 0 >> m = lgmres >> c >> call chktcg2(tolps,res,iconv) >> if (param(21).gt.0.and.tolps.gt.abs(param(21))) >> $ tolps = abs(param(21)) >> c if (param(21).lt.0) tolps = abs(param(21)) >> if (istep.eq.0) tolps = 1.e-4 >> tolpss = tolps >> c >> ntot2 = nx2*ny2*nz2*nelv >> c >> iconv = 0 >> call rzero(x,ntot2) >> >> do while(iconv.eq.0.and.iter.lt.100) >> >> if(iter.eq.0) then >> ! -1 >> call col3(r,ml,res,ntot2) ! r = L res >> c call copy(r,res,ntot2) >> else >> !update residual >> call copy(r,res,ntot2) ! r = res >> call cdabdtp(w,x,h1,h2,h2inv,intype) ! w = A x >> call add2s2(r,w,-1.,ntot2) ! r = r - w >> ! -1 >> call col2(r,ml,ntot2) ! r = L r >> endif >> ! ______ >> gamma(1) = sqrt(glsc2(r,r,ntot2)) ! gamma = \/ (r,r) >> ! 1 >> if(iter.eq.0) then >> div0 = gamma(1)*norm_fac >> if (param(21).lt.0) tolpss=abs(param(21))*div0 >> endif >> >> !check for lucky convergence >> rnorm = 0. >> if(gamma(1) .eq. 0.) goto 9000 >> temp = 1./gamma(1) >> call cmult2(v(1,1),r,temp,ntot2) ! v = r / gamma >> ! 1 1 >> do j=1,m >> iter = iter+1 >> ! -1 >> call col3(w,mu,v(1,j),ntot2) ! w = U v >> ! j >> >> etime2 = dnekclock() >> if(param(43).eq.1) then >> call uzprec(z(1,j),w,h1,h2,intype,wp) >> else ! -1 >> call hsmg_solve(z(1,j),w) ! z = M w >> endif >> etime_p = etime_p + dnekclock()-etime2 >> >> call cdabdtp(w,z(1,j), ! w = A z >> $ h1,h2,h2inv,intype) ! j >> >> ! -1 >> call col2(w,ml,ntot2) ! w = L w >> >> c !modified Gram-Schmidt >> c do i=1,j >> c h(i,j)=glsc2(w,v(1,i),ntot2) ! h = (w,v ) >> c ! i,j i >> c call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v >> c enddo ! i,j i >> >> >> c 2-PASS GS, 1st pass: >> >> do i=1,j >> h(i,j)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) >> enddo ! i,j i >> >> call gop(h(1,j),wk1,'+ ',j) ! sum over P procs >> >> do i=1,j >> call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v >> enddo ! i,j i >> >> >> c 2-PASS GS, 2nd pass: >> c >> c do i=1,j >> c wk1(i)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) >> c enddo ! i,j i >> c ! >> c call gop(wk1,wk2,'+ ',j) ! sum over P procs >> c >> c do i=1,j >> c call add2s2(w,v(1,i),-wk1(i),ntot2)! w = w - h v >> c h(i,j) = h(i,j) + wk1(i) ! i,j i >> c enddo >> >> >> !apply Givens rotations to new column >> do i=1,j-1 >> temp = h(i,j) >> h(i ,j)= c(i)*temp + s(i)*h(i+1,j) >> h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) >> enddo >> ! ______ >> alpha = sqrt(glsc2(w,w,ntot2)) ! alpha = \/ (w,w) >> rnorm = 0. >> if(alpha.eq.0.) goto 900 !converged >> l = sqrt(h(j,j)*h(j,j)+alpha*alpha) >> temp = 1./l >> c(j) = h(j,j) * temp >> s(j) = alpha * temp >> h(j,j) = l >> gamma(j+1) = -s(j) * gamma(j) >> gamma(j) = c(j) * gamma(j) >> >> c call outmat(h,m,j,' h ',j) >> >> rnorm = abs(gamma(j+1))*norm_fac >> ratio = rnorm/div0 >> if (ifprint.and.nid.eq.0) >> $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep >> 66 format(i5,1p4e12.5,i8,' Divergence') >> >> #ifndef TST_WSCAL >> if (rnorm .lt. tolpss) goto 900 !converged >> #else >> if (iter.gt.param(151)-1) goto 900 >> #endif >> if (j.eq.m) goto 1000 !not converged, restart >> >> temp = 1./alpha >> call cmult2(v(1,j+1),w,temp,ntot2) ! v = w / alpha >> ! j+1 >> enddo >> 900 iconv = 1 >> 1000 continue >> !back substitution >> ! -1 >> !c = H gamma >> do k=j,1,-1 >> temp = gamma(k) >> do i=j,k+1,-1 >> temp = temp - h(k,i)*c(i) >> enddo >> c(k) = temp/h(k,k) >> enddo >> !sum up Arnoldi vectors >> do i=1,j >> call add2s2(x,z(1,i),c(i),ntot2) ! x = x + c z >> ! i i >> enddo >> c if(iconv.eq.1) call dbg_write(x,nx2,ny2,nz2,nelv,'esol',3) >> enddo >> 9000 continue >> c >> divex = rnorm >> c iter = iter - 1 >> c >> c DIAGNOSTICS >> c call copy(w,x,ntot2) >> c if (ifvcor) then >> c xaver = glsc2(bm2,w,ntot2)/volvm2 >> c call cadd(w,-xaver,ntot2) >> c endif >> c call copy(r,res,ntot2) !r = res >> c call cdabdtp(r,w,h1,h2,h2inv,intype) ! r = A w >> c do i=1,ntot2 >> c r(i) = res(i) - r(i) ! r = res - r >> c enddo >> c call uzawa_gmres_temp(r,bm2inv,ntot2) >> c ! ______ >> c gamma(1) = sqrt(glsc2(r,r,ntot2)/volvm2) ! gamma = \/ (r,r) c >> ! 1 >> c print *, 'GMRES end resid:',gamma(1) >> c END DIAGNOSTICS >> call copy(res,x,ntot2) >> c >> if (ifvcor) then >> xaver = glsc2(bm2,res,ntot2)/volvm2 >> call cadd(res,-xaver,ntot2) >> endif >> c >> etime1 = dnekclock()-etime1 >> if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, >> & etime1 >> c call flush_hack >> 9999 format(4X,I7,' U-Pres gmres: ',I6,1p5E13.4) >> c >> c >> return >> end >> >> c----------------------------------------------------------------------- >> >> subroutine uzawa_gmres_split0(l,u,b,binv,n) >> integer n >> real l(n),u(n),b(n),binv(n) >> integer i >> do i=1,n >> l(i)=sqrt(binv(i)) >> u(i)=sqrt(b(i)) >> if(abs(u(i)*l(i)-1.0).gt.1e-13) print *, i, u(i)*l(i) >> enddo >> return >> end >> >> c----------------------------------------------------------------------- >> subroutine uzawa_gmres_split(l,u,b,binv,n) >> integer n >> real l(n),u(n),b(n),binv(n) >> integer i >> do i=1,n >> c l(i)=sqrt(binv(i)) >> c u(i)=sqrt(b(i)) >> >> c u(i)=sqrt(b(i)) >> c l(i)=1./u(i) >> >> c l(i)=sqrt(binv(i)) >> l(i)=1. >> u(i)=1./l(i) >> >> >> c if(abs(u(i)*l(i)-1.0).gt.1e-13)write(6,*) i,u(i)*l(i),' gmr_sp' >> enddo >> return >> end >> >> c----------------------------------------------------------------------- >> subroutine uzawa_gmres_temp(a,b,n) >> integer n >> real a(n),b(n) >> integer i >> do i=1,n >> a(i)=sqrt(b(i))*a(i) >> enddo >> return >> end >> c----------------------------------------------------------------------- >> subroutine ax(w,x,h1,h2,n) >> include 'SIZE' >> include 'TOTAL' >> >> c >> c w = A*x for pressure iteration >> c >> >> integer n >> real w(n),x(n),h1(n),h2(n) >> >> imsh = 1 >> isd = 1 >> call axhelm (w,x,h1,h2,imsh,isd) >> call dssum (w,nx1,ny1,nz1) >> call col2 (w,pmask,n) >> >> return >> end >> c----------------------------------------------------------------------- >> subroutine hmh_gmres(res,h1,h2,wt,iter) >> >> c Solve the Helmholtz equation by right-preconditioned c GMRES >> iteration. >> >> >> include 'SIZE' >> include 'TOTAL' >> include 'FDMH1' >> include 'GMRES' >> common /ctolpr/ divex >> common /cprint/ ifprint >> logical ifprint >> real res (lx1*ly1*lz1*lelv) >> real h1 (lx1,ly1,lz1,lelv) >> real h2 (lx1,ly1,lz1,lelv) >> real wt (lx1,ly1,lz1,lelv) >> >> common /scrcg/ d(lx1*ly1*lz1*lelv),wk(lx1*ly1*lz1*lelv) >> >> common /cgmres1/ y(lgmres) >> common /ctmp0/ wk1(lgmres),wk2(lgmres) >> real alpha, l, temp >> integer j,m >> >> logical iflag >> save iflag >> data iflag /.false./ >> real norm_fac >> save norm_fac >> >> real*8 etime1,dnekclock >> >> >> n = nx1*ny1*nz1*nelv >> >> etime1 = dnekclock() >> etime_p = 0. >> divex = 0. >> iter = 0 >> m = lgmres >> >> if(.not.iflag) then >> iflag=.true. >> call uzawa_gmres_split(ml,mu,bm1,binvm1,nx1*ny1*nz1*nelv) >> norm_fac = 1./sqrt(volvm1) >> endif >> >> call set_fdm_prec_h1b(d,h1,h2,nelv) >> if (ifvcor) smean = -1./glsum(vmult,n) >> >> call chktcg1(tolps,res,h1,h2,pmask,vmult,1,1) >> if (param(21).gt.0.and.tolps.gt.abs(param(21))) >> $ tolps = abs(param(21)) >> if (istep.eq.0) tolps = 1.e-4 >> tolpss = tolps >> c >> iconv = 0 >> call rzero(x,n) >> >> do while(iconv.eq.0.and.iter.lt.500) >> >> if(iter.eq.0) then ! -1 >> call col3(r,ml,res,n) ! r = L res >> c call copy(r,res,n) >> else >> !update residual >> call copy (r,res,n) ! r = res >> call ax (w,x,h1,h2,n) ! w = A x >> call add2s2(r,w,-1.,n) ! r = r - w >> ! -1 >> call col2(r,ml,n) ! r = L r >> endif >> ! ______ >> gamma(1) = sqrt(glsc3(r,r,wt,n)) ! gamma = \/ (r,r) >> ! 1 >> if(iter.eq.0) then >> div0 = gamma(1)*norm_fac >> if (param(21).lt.0) tolpss=abs(param(21))*div0 >> endif >> >> !check for lucky convergence >> rnorm = 0. >> if(gamma(1) .eq. 0.) goto 9000 >> temp = 1./gamma(1) >> call cmult2(v(1,1),r,temp,n) ! v = r / gamma >> ! 1 1 >> do j=1,m >> iter = iter+1 >> ! -1 >> call col3(w,mu,v(1,j),n) ! w = U v >> ! j >> >> c . . . . . Overlapping Schwarz + coarse-grid . . . . . . . >> >> etime2 = dnekclock() >> kfldfdm = ndim+1 >> call fdm_h1 >> $ (z(1,j),w,d,pmask,vmult,nelv,ktype(1,1,kfldfdm),wk) >> call crs_solve_h1 (wk,w) c call hsmg_solve(z(1,j),w) >> ! z = M w >> ! j >> call add2 (z(1,j),wk,n) >> if (ifvcor) then >> rmean = smean*glsc2(z(1,j),vmult,n) >> call cadd(z(1,j),rmean,n) >> endif >> etime_p = etime_p + dnekclock()-etime2 >> c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> >> >> call ax (w,z(1,j),h1,h2,n) ! w = A z >> ! j >> >> ! -1 >> call col2(w,ml,n) ! w = L w >> >> c !modified Gram-Schmidt >> >> c do i=1,j >> c h(i,j)=glsc3(w,v(1,i),wt,n) ! h = (w,v ) >> c ! i,j i >> >> c call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v >> c enddo ! i,j i >> >> c 2-PASS GS, 1st pass: >> >> do i=1,j >> h(i,j)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) >> enddo ! i,j i >> >> call gop(h(1,j),wk1,'+ ',j) ! sum over P procs >> >> do i=1,j >> call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v >> enddo ! i,j i >> >> >> c 2-PASS GS, 2nd pass: >> c >> c do i=1,j >> c wk1(i)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) >> c enddo ! i,j i >> c ! >> c call gop(wk1,wk2,'+ ',j) ! sum over P procs >> c >> c do i=1,j >> c call add2s2(w,v(1,i),-wk1(i),n) ! w = w - h v >> c h(i,j) = h(i,j) + wk1(i) ! i,j i >> c enddo >> >> !apply Givens rotations to new column >> do i=1,j-1 >> temp = h(i,j) >> h(i ,j)= c(i)*temp + s(i)*h(i+1,j) >> h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) >> enddo >> ! ______ >> alpha = sqrt(glsc3(w,w,wt,n)) ! alpha = \/ (w,w) >> rnorm = 0. >> if(alpha.eq.0.) goto 900 !converged >> l = sqrt(h(j,j)*h(j,j)+alpha*alpha) >> temp = 1./l >> c(j) = h(j,j) * temp >> s(j) = alpha * temp >> h(j,j) = l >> gamma(j+1) = -s(j) * gamma(j) >> gamma(j) = c(j) * gamma(j) >> >> rnorm = abs(gamma(j+1))*norm_fac >> ratio = rnorm/div0 >> if (ifprint.and.nid.eq.0) >> $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep >> 66 format(i5,1p4e12.5,i8,' Divergence') >> >> #ifndef TST_WSCAL >> if (rnorm .lt. tolpss) goto 900 !converged >> #else >> if (iter.gt.param(151)-1) goto 900 >> #endif >> if (j.eq.m) goto 1000 !not converged, restart >> >> temp = 1./alpha >> call cmult2(v(1,j+1),w,temp,n) ! v = w / alpha >> ! j+1 >> enddo >> 900 iconv = 1 >> 1000 continue >> !back substitution >> ! -1 >> !c = H gamma >> do k=j,1,-1 >> temp = gamma(k) >> do i=j,k+1,-1 >> temp = temp - h(k,i)*c(i) >> enddo >> c(k) = temp/h(k,k) >> enddo >> !sum up Arnoldi vectors >> do i=1,j >> call add2s2(x,z(1,i),c(i),n) ! x = x + c z >> enddo ! i i >> c if(iconv.eq.1) call dbg_write(x,nx1,ny1,nz1,nelv,'esol',3) >> enddo >> 9000 continue >> c >> divex = rnorm >> call copy(res,x,n) >> c >> if (ifvcor) then >> xaver = glsc2(bm1,res,n)/volvm1 >> call cadd(res,-xaver,n) >> endif >> c >> etime1 = dnekclock()-etime1 >> if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, >> & etime1 >> c call flush_hack >> 9999 format(4X,I7,' PRES gmres: ',I6,1p5E13.4) >> >> return >> end >> c----------------------------------------------------------------------- >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Apr 21 10:07:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 10:07:52 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: Message-ID: <552252613.10244171271862472581.JavaMail.root@neo-mail-3> Hi Paul, Yes I am checking it right now. The midside nodes on the top layer and bottom layer are working, however the elements in the layers between are not. They are all generated the same way, so at the moment I'm not sure. When I remove the curved side section in the rea, it works both for the fine and coarse lofts. I'm not sure why it doesn't like the midpoints; it's almost as if it is placing them in the wrong place and fitting a parabola that interferes with surrounding geometry. I'll look into it more here and post again when I have an update. Thanks Paul - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, April 21, 2010 10:00:29 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Vanishing Jacobian error description Michael, I looked at this for a couple of different N. nek/postx think that the geometry is messed up --- see www.mcs.anl.gov/~fischer/zzz.jpg That being said, it could easily be a problem w/ the midside node support that I added last month. (NOTE: to see the geometry I had to fix something in the nek code -- normally when you get vanishing jacobian the code will output "xyzblah.fld01" with the geometry, so that you can then look at this in postx or visit. For pn/pn, this was broken but is now working in the just-updated repo.) Do you have a way to verify that your lofting is working? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Sorry, yes that was for without the curve side data. Here is the case that includes the curved side data. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 U S/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, nek5000-users at lists.mcs.anl.gov 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+0 0 >> 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 > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 10:39:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 17:39:09 +0200 Subject: [Nek5000-users] visit: looking at velocity components when using the .vtk-format Message-ID: <4BCF1C1D.3030807@mech.kth.se> Hi, I am currently doing post-processing computations on some nek data where I don't have the data in the *.f???? format. So, when I write out the (postprocessed) data I simply use the vtk format. I am using the "DATASET STRUCTURED_GRID" option and "VECTORS" for the velocity. When I read the data into visit I only get the option to visualize vector magnitude. Is there a way to also look at velocity components u,v,w? For some reason (it appears to me) visit by default computes the magnitude and throws the individual components away. Is there a way to get around this? Thanks! Best regards Johan From nek5000-users at lists.mcs.anl.gov Wed Apr 21 10:46:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 08:46:32 -0700 Subject: [Nek5000-users] visit: looking at velocity components when using the .vtk-format In-Reply-To: <4BCF1C1D.3030807@mech.kth.se> References: <4BCF1C1D.3030807@mech.kth.se> Message-ID: Hi Johan, VisIt shouldn't do this ... I don't know what's going wrong, but if there is vector data in the file, VisIt should preserve it. Can you get in touch with me at hchilds at lbl.gov and get me the VTK file? I'll take a look. Best, Hank On Wed, Apr 21, 2010 at 8:39 AM, wrote: > Hi, > > I am currently doing post-processing computations on some nek data where > I don't have the data in the *.f???? format. So, when I write out the > (postprocessed) data I simply use the vtk format. > I am using the "DATASET STRUCTURED_GRID" option > and "VECTORS" for the velocity. When I read the data into visit I only > get the option to visualize vector magnitude. Is there a way to also > look at velocity components u,v,w? For some reason (it appears to me) > visit by default computes the magnitude and throws the individual > components away. Is there a way to get around this? > > Thanks! > > Best regards > > Johan > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Apr 21 10:48:30 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 10:48:30 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <61371667.10281161271864885885.JavaMail.root@neo-mail-3> Message-ID: <897519058.10281411271864910783.JavaMail.root@neo-mail-3> Paul, I figured out the issue, and it was a mistake in the routine I was using to put the elements midside nodes in the correct locations. I fixed the issue and you can see the attached result case and image if you (or anyone) would like. I should note that this geometry, although simple, was created by: 1. Modeled in Solidworks 2. Imported into Gambit 3. Meshed in Gambit 4. Run through our matLab code to generate rea file This is the result, a proof of concept. If you think there would be significant interest I can post a separate email to the user list, so it is not buried in this "vanishing Jacobian" topic. Regards, Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, April 21, 2010 10:07:52 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Vanishing Jacobian error description Hi Paul, Yes I am checking it right now. The midside nodes on the top layer and bottom layer are working, however the elements in the layers between are not. They are all generated the same way, so at the moment I'm not sure. When I remove the curved side section in the rea, it works both for the fine and coarse lofts. I'm not sure why it doesn't like the midpoints; it's almost as if it is placing them in the wrong place and fitting a parabola that interferes with surrounding geometry. I'll look into it more here and post again when I have an update. Thanks Paul - Michael ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, April 21, 2010 10:00:29 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Vanishing Jacobian error description Michael, I looked at this for a couple of different N. nek/postx think that the geometry is messed up --- see www.mcs.anl.gov/~fischer/zzz.jpg That being said, it could easily be a problem w/ the midside node support that I added last month. (NOTE: to see the geometry I had to fix something in the nek code -- normally when you get vanishing jacobian the code will output "xyzblah.fld01" with the geometry, so that you can then look at this in postx or visit. For pn/pn, this was broken but is now working in the just-updated repo.) Do you have a way to verify that your lofting is working? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Sorry, yes that was for without the curve side data. Here is the case that includes the curved side data. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 U S/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, nek5000-users at lists.mcs.anl.gov 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+0 0 >> 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 > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test4.tar Type: application/x-tar Size: 11987 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: visit0001.tif Type: image/tiff Size: 155582 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 10:52:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 17:52:48 +0200 Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <897519058.10281411271864910783.JavaMail.root@neo-mail-3> References: <897519058.10281411271864910783.JavaMail.root@neo-mail-3> Message-ID: <87F9C278-13FD-432A-9EBF-EB9D7EA91F46@lav.mavt.ethz.ch> Great! Any chance to change your MATLAB code into C or Fortran? Stefan On Apr 21, 2010, at 5:48 PM, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > I figured out the issue, and it was a mistake in the routine I was using to put the elements midside nodes in the correct locations. I fixed the issue and you can see the attached result case and image if you (or anyone) would like. > > I should note that this geometry, although simple, was created by: > > 1. Modeled in Solidworks > 2. Imported into Gambit > 3. Meshed in Gambit > 4. Run through our matLab code to generate rea file > > This is the result, a proof of concept. If you think there would be significant interest I can post a separate email to the user list, so it is not buried in this "vanishing Jacobian" topic. > > Regards, > Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 10:07:52 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > Hi Paul, > > Yes I am checking it right now. The midside nodes on the top layer and bottom layer are working, however the elements in the layers between are not. They are all generated the same way, so at the moment I'm not sure. > > When I remove the curved side section in the rea, it works both for the fine and coarse lofts. I'm not sure why it doesn't like the midpoints; it's almost as if it is placing them in the wrong place and fitting a parabola that interferes with surrounding geometry. I'll look into it more here and post again when I have an update. > > Thanks Paul > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 10:00:29 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > Michael, I looked at this for a couple of different N. nek/postx think that the geometry is messed up --- see www.mcs.anl.gov/~fischer/zzz.jpg That being said, it could easily be a problem w/ the midside node support that I added last month. (NOTE: to see the geometry I had to fix something in the nek code -- normally when you get vanishing jacobian the code will output "xyzblah.fld01" with the geometry, so that you can then look at this in postx or visit. For pn/pn, this was broken but is now working in the just-updated repo.) Do you have a way to verify that your lofting is working? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Sorry, yes that was for without the curve side data. Here is the case that includes the curved side data. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010,nek5000-users at lists.mcs.anl.gov 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: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 U S/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, nek5000-users at lists.mcs.anl.gov 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+0 0 >> 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 >Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 11:04:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 18:04:32 +0200 Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <897519058.10281411271864910783.JavaMail.root@neo-mail-3> References: <897519058.10281411271864910783.JavaMail.root@neo-mail-3> Message-ID: <4BCF2210.9000208@univ-lyon1.fr> Michael, I am very interested in the whole procedure. Do you think that this could be an efficient way to generate meshes for complex 3D domains ? What kind of output do you generate with Solidworks and Gambit ? .msh ? The Matlab code has also aroused my curiosity... that could be helpful. Regards, Michael B. nek5000-users at lists.mcs.anl.gov a ?crit : > Paul, > > I figured out the issue, and it was a mistake in the routine I was > using to put the elements midside nodes in the correct locations. I > fixed the issue and you can see the attached result case and image if > you (or anyone) would like. > > I should note that this geometry, although simple, was created by: > > 1. Modeled in Solidworks > 2. Imported into Gambit > 3. Meshed in Gambit > 4. Run through our matLab code to generate rea file > > This is the result, a proof of concept. If you think there would be > significant interest I can post a separate email to the user list, so > it is not buried in this "vanishing Jacobian" topic. > > Regards, > Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 10:07:52 AM GMT -06:00 Guadalajara / > Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > Hi Paul, > > Yes I am checking it right now. The midside nodes on the top layer and > bottom layer are working, however the elements in the layers between > are not. They are all generated the same way, so at the moment I'm not > sure. > > When I remove the curved side section in the rea, it works both for > the fine and coarse lofts. I'm not sure why it doesn't like the > midpoints; it's almost as if it is placing them in the wrong place and > fitting a parabola that interferes with surrounding geometry. I'll > look into it more here and post again when I have an update. > > Thanks Paul > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 10:00:29 AM GMT -06:00 Guadalajara / > Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > Michael, I looked at this for a couple of different N. nek/postx think > that the geometry is messed up --- see > www.mcs.anl.gov/~fischer/zzz.jpg That being said, it could easily be a > problem w/ the midside node support that I added last month. (NOTE: to > see the geometry I had to fix something in the nek code -- normally > when you get vanishing jacobian the code will output "xyzblah.fld01" > with the geometry, so that you can then look at this in postx or > visit. For pn/pn, this was broken but is now working in the > just-updated repo.) Do you have a way to verify that your lofting is > working? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov > wrote: > Hi, > > Sorry, yes that was for without the curve side data. > Here is the case that includes the curved side data. > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 > 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: > Re: [Nek5000-users] Vanishing Jacobian error description > > The case > you sent runs fine.... is it w/ or w/o the curved side info? Paul On > Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: > nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: > Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 U S/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, > nek5000-users at lists.mcs.anl.gov 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+0 0 >> 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 > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ Nek5000-users mailing > list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing > list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing > list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 11:17:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 11:17:05 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <897519058.10281411271864910783.JavaMail.root@neo-mail-3> References: <897519058.10281411271864910783.JavaMail.root@neo-mail-3> Message-ID: Hi Michael, Thanks! I'm sure there would be some interest. Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > I figured out the issue, and it was a mistake in the routine I was using to put the elements midside nodes in the correct locations. I fixed the issue and you can see the attached result case and image if you (or anyone) would like. > > I should note that this geometry, although simple, was created by: > > 1. Modeled in Solidworks > 2. Imported into Gambit > 3. Meshed in Gambit > 4. Run through our matLab code to generate rea file > > This is the result, a proof of concept. If you think there would be significant interest I can post a separate email to the user list, so it is not buried in this "vanishing Jacobian" topic. > > Regards, > Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 10:07:52 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > > Hi Paul, > > Yes I am checking it right now. The midside nodes on the top layer and bottom layer are working, however the elements in the layers between are not. They are all generated the same way, so at the moment I'm not sure. > > When I remove the curved side section in the rea, it works both for the fine and coarse lofts. I'm not sure why it doesn't like the midpoints; it's almost as if it is placing them in the wrong place and fitting a parabola that interferes with surrounding geometry. I'll look into it more here and post again when I have an update. > > Thanks Paul > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 10:00:29 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > Michael, I looked at this for a couple of different N. nek/postx think that the geometry is messed up --- see www.mcs.anl.gov/~fischer/zzz.jpg That being said, it could easily be a problem w/ the midside node support that I added last month. (NOTE: to see the geometry I had to fix something in the nek code -- normally when you get vanishing jacobian the code will output "xyzblah.fld01" with the geometry, so that you can then look at this in postx or visit. For pn/pn, this was broken but is now working in the just-updated repo.) Do you have a way to verify that your lofting is working? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > Sorry, yes that was for without the curve side data. Here is the case that includes the curved side data. > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monter rey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 U S/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, nek5000-users at lists.mcs.anl.gov 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.40692804605498586 E-002 -7.79619559165757245E-003 >> 0 xyz: 2.65874E-01 3.54498E-01 2.87050E+0 0 >> 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 > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 11:25:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 11:25:54 -0500 (CDT) Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <87F9C278-13FD-432A-9EBF-EB9D7EA91F46@lav.mavt.ethz.ch> Message-ID: <1237429119.10300841271867154640.JavaMail.root@neo-mail-3> Hey Stefan, I do not know C, and I am still learning the in & outs of Fortran .? I certainly think it is possible though. I do use some built in functions that matlab offers to make my life easier, but I'm sure they can be replaced with?if needed. Michael B, I'm still testing various geometries, becoming more complex each time.?Our research group is using Nek with applications to Gas turbines, so our motivation to pursue this was indeed because of complex geometries.? From Solidworks , you can export as a " ParaSolid ".? You can then Import this ParaSolid into Gambit. From Gambit, I export a generic Mesh which is a . NEU (neutral file).? This is what the matLab code uses, the . neu file.? There are many middle steps, but the process seems to work. I think there is plenty of room for improvement, but at the moment I'm still testing new geometries. - Michael M. ----- Original Message ----- From: nek5000-users at lists. mcs . anl .gov To: nek5000-users at lists. mcs . anl .gov Sent: Wednesday, April 21, 2010 10:52:48 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Vanishing Jacobian error description Great! Any chance to change your MATLAB code into C or Fortran ? Stefan On Apr 21, 2010, at 5:48 PM, nek5000-users at lists. mcs . anl .gov wrote: Paul, I figured out the issue, and it was a mistake in the routine I was using to put the elements midside nodes in the correct locations. I fixed the issue and you can see the attached result case and image if you (or anyone) would like. I should note that this geometry, although simple, was created by: 1.? Modeled in Solidworks ? ? 2.? Imported into Gambit 3. Meshed in Gambit 4. Run through our matLab code to generate rea file This is the result, a proof of concept.? If you think there would be significant interest I can post a separate email to the user list, so it is not buried in this "vanishing Jacobian " topic. Regards, Michael ----- Original Message ----- From: ? nek5000-users at lists. mcs . anl .gov To: ? nek5000-users at lists. mcs . anl .gov Sent: Wednesday, April 21, 2010 10:07:52 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Vanishing Jacobian error description Hi Paul, Yes I am checking it right now. The midside nodes on the top layer and bottom layer are working, however the elements in the layers between are not. They are all generated the same way, so at the moment I'm not sure. ? When I remove the curved side section in the rea , it works both for the fine and coarse lofts. I'm not sure why it doesn't like the midpoints; it's almost as if it is placing them in the wrong place and fitting a parabola that interferes with surrounding geometry.? I'll look into it more here and post again when I have an update. ? Thanks Paul - Michael ----- Original Message ----- From: ? nek5000-users at lists. mcs . anl .gov To: ? nek5000-users at lists. mcs . anl .gov Sent: Wednesday, April 21, 2010 10:00:29 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Vanishing Jacobian error description Michael, I looked at this for a couple of different N. nek / postx think that the geometry is messed up --- see ? www . mcs . anl .gov/~ fischer / zzz . jpg ? That being said, it could easily be a problem w/ the midside node support that I added last month. (NOTE: to see the geometry I had to fix something in the nek code -- normally when you get vanishing jacobian the code will output " xyzblah .fld01" with the geometry, so that you can then look at this in postx or visit. For pn / pn , this was broken but is now working in the just-updated repo .) Do you have a way to verify that your lofting is working? Paul On Wed, 21 Apr 2010, ? nek5000-users at lists. mcs . anl .gov ? wrote: > Hi, > > Sorry, yes that was for without the curve side data. Here is the case that includes the curved side data. > > - Michael > > ----- Original Message ----- > From: ? nek5000-users at lists. mcs . anl .gov ? > To: ? nek5000-users at lists. mcs . anl .gov ? > Sent: Wednesday, April 21, 2010 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > The case you sent runs fine.... is it w/ or w/o the curved side info? Paul On Wed, 21 Apr 2010, nek5000-users at lists. mcs . anl .gov ? 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: ? nek5000-users at lists. mcs . anl .gov ? > To: " Nekton User List" > Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 U S/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, ? nek5000-users at lists. mcs . anl .gov ? 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+0 0 >> 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 > Nek5000-users at lists. mcs . anl .gov ? > ? https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users ? > > _______________________________________________ Nek5000-users mailing list ? Nek5000-users at lists. mcs . anl .gov ? https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users _______________________________________________ Nek5000-users mailing list ? Nek5000-users at lists. mcs . anl .gov ? https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users _______________________________________________ Nek5000-users mailing list ? Nek5000-users at lists. mcs . anl .gov ? https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists. mcs . anl .gov https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists. mcs . anl .gov https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 11:29:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 18:29:34 +0200 Subject: [Nek5000-users] Vanishing Jacobian error description In-Reply-To: <897519058.10281411271864910783.JavaMail.root@neo-mail-3> References: <897519058.10281411271864910783.JavaMail.root@neo-mail-3> Message-ID: <1271867374.31181.80.camel@localhost.localdomain> Hi Michael, That indeed sounds like a potentially very useful path to getting geometries into NEK. Definitely interested in more details. Cheers, Frank On Wed, 2010-04-21 at 10:48 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > I figured out the issue, and it was a mistake in the routine I was > using to put the elements midside nodes in the correct locations. I > fixed the issue and you can see the attached result case and image if > you (or anyone) would like. > > I should note that this geometry, although simple, was created by: > > 1. Modeled in Solidworks > 2. Imported into Gambit > 3. Meshed in Gambit > 4. Run through our matLab code to generate rea file > > This is the result, a proof of concept. If you think there would be > significant interest I can post a separate email to the user list, so > it is not buried in this "vanishing Jacobian" topic. > > Regards, > Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 10:07:52 AM GMT -06:00 Guadalajara / > Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > Hi Paul, > > Yes I am checking it right now. The midside nodes on the top layer and > bottom layer are working, however the elements in the layers between > are not. They are all generated the same way, so at the moment I'm not > sure. > > When I remove the curved side section in the rea, it works both for > the fine and coarse lofts. I'm not sure why it doesn't like the > midpoints; it's almost as if it is placing them in the wrong place and > fitting a parabola that interferes with surrounding geometry. I'll > look into it more here and post again when I have an update. > > Thanks Paul > > - Michael > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 10:00:29 AM GMT -06:00 Guadalajara / > Mexico City / Monterrey > Subject: Re: [Nek5000-users] Vanishing Jacobian error description > > Michael, I looked at this for a couple of different N. nek/postx think > that the geometry is messed up --- see > www.mcs.anl.gov/~fischer/zzz.jpg That being said, it could easily be a > problem w/ the midside node support that I added last month. (NOTE: to > see the geometry I had to fix something in the nek code -- normally > when you get vanishing jacobian the code will output "xyzblah.fld01" > with the geometry, so that you can then look at this in postx or > visit. For pn/pn, this was broken but is now working in the > just-updated repo.) Do you have a way to verify that your lofting is > working? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov > wrote: > Hi, > > Sorry, yes that was for without the curve side data. > Here is the case that includes the curved side data. > > - Michael > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > Sent: Wednesday, April 21, 2010 > 8:39:38 AM GMT -06:00 Guadalajara / Mexico City / Monterrey > Subject: > Re: [Nek5000-users] Vanishing Jacobian error description > > The case > you sent runs fine.... is it w/ or w/o the curved side info? Paul On > Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov 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: > nek5000-users at lists.mcs.anl.gov > To: "Nekton User List" > Sent: > Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 U S/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, > nek5000-users at lists.mcs.anl.gov 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+0 0 >> 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 > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ Nek5000-users mailing > list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing > list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing > list Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 21 12:01:35 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 19:01:35 +0200 Subject: [Nek5000-users] Visit and NEK files In-Reply-To: References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> Message-ID: <1271869295.27338.5.camel@localhost.localdomain> Hello all, I am looking for a way to tell NEK to switch between writing out *.fld?? and *.f???? files. Also, Visit has problems with (temporal) sequences of *.fld?? files that exceed 99. a.fld01 ... a.fld99 is OK, but a.fld100 doesn't fit into the metadata format. Can the number of digits in the names of the *.fld?? files be increased. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 21 12:08:03 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 10:08:03 -0700 Subject: [Nek5000-users] Visit and NEK files In-Reply-To: <1271869295.27338.5.camel@localhost.localdomain> References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> <1271869295.27338.5.camel@localhost.localdomain> Message-ID: > I am looking for a way to tell NEK to switch between writing out *.fld?? > and *.f???? files. ?Also, Visit has problems with (temporal) sequences > of *.fld?? files that exceed 99. ?a.fld01 ... a.fld99 is OK, but > a.fld100 doesn't fit into the metadata format. ?Can the number of digits > in the names of the *.fld?? files be increased. Hi Frank, I'll look into "a.fld100" support for VisIt. Someone else will need to respond to the question about switching between .fld and .f???? files. Best, Hank From nek5000-users at lists.mcs.anl.gov Wed Apr 21 12:11:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 19:11:25 +0200 Subject: [Nek5000-users] Visit and NEK files In-Reply-To: References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> <1271869295.27338.5.camel@localhost.localdomain> Message-ID: <72A1C3FD-F7BA-4D30-BB91-DD462C9F50AB@lav.mavt.ethz.ch> I am not sure if it is worth the trouble. The old fld format (ASCII/BINRAY) should only be used for debugging. Again, the production format is the new .f???? format. Stefan On Apr 21, 2010, at 7:08 PM, nek5000-users at lists.mcs.anl.gov wrote: >> I am looking for a way to tell NEK to switch between writing out *.fld?? >> and *.f???? files. Also, Visit has problems with (temporal) sequences >> of *.fld?? files that exceed 99. a.fld01 ... a.fld99 is OK, but >> a.fld100 doesn't fit into the metadata format. Can the number of digits >> in the names of the *.fld?? files be increased. > > Hi Frank, > > I'll look into "a.fld100" support for VisIt. Someone else will need > to respond to the question about switching between .fld and .f???? > files. > > Best, > Hank > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 12:17:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 19:17:16 +0200 Subject: [Nek5000-users] Visit and NEK files In-Reply-To: <1271869295.27338.5.camel@localhost.localdomain> References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> <1271869295.27338.5.camel@localhost.localdomain> Message-ID: <4C842F2F-FAD7-476A-8C84-4CEB86928F06@lav.mavt.ethz.ch> In general you can specify the output/input format using param(67) and param(66). Use a positive number (including 0) for the new binary *.f???? format. A negative number is for ASCII fld-files. To get the old binary fld format set param(.) = 4 in the .usr file. You cannot use the .rea in this case! Stefan On Apr 21, 2010, at 7:01 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I am looking for a way to tell NEK to switch between writing out *.fld?? > and *.f???? files. Also, Visit has problems with (temporal) sequences > of *.fld?? files that exceed 99. a.fld01 ... a.fld99 is OK, but > a.fld100 doesn't fit into the metadata format. Can the number of digits > in the names of the *.fld?? files be increased. > > Cheers, > Frank > > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 12:42:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 19:42:32 +0200 Subject: [Nek5000-users] to Hank In-Reply-To: References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> <1271869295.27338.5.camel@localhost.localdomain> Message-ID: <1271871752.27338.16.camel@localhost.localdomain> Hello Hank, Is the new *.f???? format supported by Visit? I can read it in without an error, but there is no data, not even a mesh is present. The data file is: http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d0.f0001 I use the following meta data file: NEK5000 version: 1.0 filetemplate: c203d0.f%04d firsttimestep: 1 numtimesteps: 1 Cheers, Frank On Wed, 2010-04-21 at 10:08 -0700, nek5000-users at lists.mcs.anl.gov wrote: > > I am looking for a way to tell NEK to switch between writing out *.fld?? > > and *.f???? files. Also, Visit has problems with (temporal) sequences > > of *.fld?? files that exceed 99. a.fld01 ... a.fld99 is OK, but > > a.fld100 doesn't fit into the metadata format. Can the number of digits > > in the names of the *.fld?? files be increased. > > Hi Frank, > > I'll look into "a.fld100" support for VisIt. Someone else will need > to respond to the question about switching between .fld and .f???? > files. > > Best, > Hank > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Wed Apr 21 12:47:22 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 19:47:22 +0200 Subject: [Nek5000-users] to Hank In-Reply-To: <1271871752.27338.16.camel@localhost.localdomain> References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> <1271869295.27338.5.camel@localhost.localdomain> <1271871752.27338.16.camel@localhost.localdomain> Message-ID: <1229E440-F35A-4E37-9723-51D6001FCDE6@lav.mavt.ethz.ch> Yes the *.f???? is supported by VisIt. Your file template is wrong. Try again with: filetemplate: c203d%01d.f%04d Stefan On Apr 21, 2010, at 7:42 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Hank, > > Is the new *.f???? format supported by Visit? I can read it in without > an error, but there is no data, not even a mesh is present. > > The data file is: > http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/c203d0.f0001 > > I use the following meta data file: > NEK5000 > version: 1.0 > filetemplate: c203d0.f%04d > firsttimestep: 1 > numtimesteps: 1 > > Cheers, > Frank > > > On Wed, 2010-04-21 at 10:08 -0700, nek5000-users at lists.mcs.anl.gov > wrote: >>> I am looking for a way to tell NEK to switch between writing out *.fld?? >>> and *.f???? files. Also, Visit has problems with (temporal) sequences >>> of *.fld?? files that exceed 99. a.fld01 ... a.fld99 is OK, but >>> a.fld100 doesn't fit into the metadata format. Can the number of digits >>> in the names of the *.fld?? files be increased. >> >> Hi Frank, >> >> I'll look into "a.fld100" support for VisIt. Someone else will need >> to respond to the question about switching between .fld and .f???? >> files. >> >> Best, >> Hank >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 12:57:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 12:57:52 -0500 (CDT) Subject: [Nek5000-users] Visit and NEK files In-Reply-To: <1271869295.27338.5.camel@localhost.localdomain> References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> <1271869295.27338.5.camel@localhost.localdomain> Message-ID: Hi Frank, comment out the param(66)=4 stmt in the .usr file and you will get the production file format --- At present this cannot be read by postx. Both formats work with VisIt, and there is no problem in going to 1000s of files with either format -- we do this regularly. Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, I am looking for a way to tell NEK to switch between writing out *.fld?? and *.f???? files. Also, Visit has problems with (temporal) sequences of *.fld?? files that exceed 99. a.fld01 ... a.fld99 is OK, but a.fld100 doesn't fit into the metadata format. Can the number of digits in the names of the *.fld?? files be increased. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 13:00:32 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 20:00:32 +0200 Subject: [Nek5000-users] Visit and NEK files In-Reply-To: References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> <1271869295.27338.5.camel@localhost.localdomain> Message-ID: Paul, > Both formats work with VisIt, and there is no problem > in going to 1000s of files with either format -- we do > this regularly. this only works for the *.f???? format. The fld file fomat does not feature leading zeros in the file name. The NEK reader in VisIt cannot handle that at the moment. Stefan > > Paul > > > On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello all, > > I am looking for a way to tell NEK to switch between writing out *.fld?? > and *.f???? files. Also, Visit has problems with (temporal) sequences > of *.fld?? files that exceed 99. a.fld01 ... a.fld99 is OK, but > a.fld100 doesn't fit into the metadata format. Can the number of digits > in the names of the *.fld?? files be increased. > > Cheers, > Frank > > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users_______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 13:10:13 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 20:10:13 +0200 Subject: [Nek5000-users] Visit and NEK files In-Reply-To: References: <1271850746.31181.40.camel@localhost.localdomain> <7A7188EF-F713-481E-B70D-AEBE89F47DD0@lav.mavt.ethz.ch> <1271851341.31181.50.camel@localhost.localdomain> <1271869295.27338.5.camel@localhost.localdomain> Message-ID: <0DDAA920-A7D6-4B9D-974D-8250B72173FE@lav.mavt.ethz.ch> Ok take it back. The old format works even for 1000s of files! Stefan On Apr 21, 2010, at 8:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > >> Both formats work with VisIt, and there is no problem >> in going to 1000s of files with either format -- we do >> this regularly. > > this only works for the *.f???? format. The fld file fomat does not feature leading zeros in the file name. The NEK reader in VisIt cannot handle that at the moment. > > Stefan > > >> >> Paul >> >> >> On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >> >> I am looking for a way to tell NEK to switch between writing out *.fld?? >> and *.f???? files. Also, Visit has problems with (temporal) sequences >> of *.fld?? files that exceed 99. a.fld01 ... a.fld99 is OK, but >> a.fld100 doesn't fit into the metadata format. Can the number of digits >> in the names of the *.fld?? files be increased. >> >> Cheers, >> Frank >> >> >> >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users_______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 21 14:20:15 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 14:20:15 -0500 Subject: [Nek5000-users] Detected non-right-handed element.. Message-ID: Hello, In the latest repo (491), I get the following error : WARNINGb: Detected non-right-handed element. Number 1 V1-8: -0.2133E-01 -0.2133E-01 0.0000E+00 0.0000E+00 0.9570E-03 0.9570E-03 0.9570E-03 0.9570E-03 call exitt: dying ... However, the version I was using previously (479) did not have any problem while compiling or during simulations. Any thoughts ? Thanks for any help.. Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 15:59:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 15:59:53 -0500 (CDT) Subject: [Nek5000-users] Detected non-right-handed element.. In-Reply-To: References: Message-ID: Shriram, Can you post or send a gzip'd copy of your .rea/.usr file? Thanks, Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > In the latest repo (491), I get the following error : > > > WARNINGb: Detected non-right-handed element. > Number 1 V1-8: -0.2133E-01 -0.2133E-01 0.0000E+00 0.0000E+00 > 0.9570E-03 0.9570E-03 0.9570E-03 0.9570E-03 > > call exitt: dying ... > > > However, the version I was using previously (479) did not have any problem > while compiling or during simulations. Any thoughts ? > Thanks for any help.. > > Regards > Shriram > From nek5000-users at lists.mcs.anl.gov Wed Apr 21 16:43:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 16:43:52 -0500 Subject: [Nek5000-users] Detected non-right-handed element.. In-Reply-To: References: Message-ID: Paul, Please find attached the rea and usr files. Thanks for your help. Regards Shriram Jagannathan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: first.rea.gz Type: application/x-gzip Size: 196049 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: first.usr.gz Type: application/x-gzip Size: 2540 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 21 20:33:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 21 Apr 2010 20:33:44 -0500 (CDT) Subject: [Nek5000-users] Detected non-right-handed element.. In-Reply-To: References: Message-ID: Hi Shriram, I was able to run this w/ the current repo. You might want to verify your makenek script, SIZE file, etc. ? Paul On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Paul, > > Please find attached the rea and usr files. Thanks for your help. > > Regards > Shriram Jagannathan > From nek5000-users at lists.mcs.anl.gov Thu Apr 22 02:28:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 09:28:58 +0200 Subject: [Nek5000-users] Periodic flow around sphere Message-ID: <4BCFFABA.6060703@kit.edu> Dear NEKs, I'm trying to compute periodic channel flow around a sphere. The grid I made with Prenek (SPHERICAL MESH). But the run is always crashing after some timesteps. I tried with different meshes and configurations but it never run through... I attached the .rea, .usr, SIZE and output files. Best, Fred -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SIZE URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sphere.rea URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sphere.usr URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_sphere2.o1830 URL: From nek5000-users at lists.mcs.anl.gov Thu Apr 22 03:03:14 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 03:03:14 -0500 (CDT) Subject: [Nek5000-users] Periodic flow around sphere In-Reply-To: <4BCFFABA.6060703@kit.edu> References: <4BCFFABA.6060703@kit.edu> Message-ID: Hi Fred, when I view this in postx I get the impression that there are two nested meshes there... One associated with the sphere, the other looks like a std. periodic box ? (box first, sphere second) What tipped me off is that your number of elements is not divisible by 6, and that when I selected to plot face 5, some faces that are not part of the std. spherical mesh configuration showed up. Checking further... Paul On Thu, 22 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear NEKs, > > I'm trying to compute periodic channel flow around a sphere. The grid I made > with Prenek (SPHERICAL MESH). But the run is always crashing after some > timesteps. I tried with different meshes and configurations but it never run > through... > > I attached the .rea, .usr, SIZE and output files. > > Best, Fred > From nek5000-users at lists.mcs.anl.gov Thu Apr 22 03:14:17 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 03:14:17 -0500 (CDT) Subject: [Nek5000-users] Periodic flow around sphere In-Reply-To: References: <4BCFFABA.6060703@kit.edu> Message-ID: To be more precise - by nested, I really meant that there are elements that overlap the same regions... this would be very confusing to genmap/nek --- it's one of the cases for which we don't currently have any checks (it's not easy in the general case... though I think I might now have some ideas on how to get at least _some_ type of checking in place) Paul On Thu, 22 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Fred, when I view this in postx I get the impression that there > are two nested meshes there... One associated with the sphere, the > other looks like a std. periodic box ? (box first, sphere second) > > What tipped me off is that your number of elements is not divisible > by 6, and that when I selected to plot face 5, some faces that are > not part of the std. spherical mesh configuration showed up. > > Checking further... > > Paul > > > On Thu, 22 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear NEKs, >> >> I'm trying to compute periodic channel flow around a sphere. The grid I >> made with Prenek (SPHERICAL MESH). But the run is always crashing after >> some timesteps. I tried with different meshes and configurations but it >> never run through... >> >> I attached the .rea, .usr, SIZE and output files. >> >> Best, Fred >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Apr 22 03:47:56 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 10:47:56 +0200 Subject: [Nek5000-users] Nekmerge question Message-ID: <4BD00D3C.4090809@gmail.com> Hello all, I know there already exists a thread having the same title dating back to November 2009, but no one has answered to it yet. I also have some question regarding nekmerge. I would like to mesh the cross-section of a cylindrical pipe. Using the cylindrical version of genbox, I obviously get into troubles as soon as I include the axis. As a consequence, I would like to merge two meshes: - a cartesian one in the vicinity of the axis - a cylindrical one for the rest of the pipe Once I genboxed the corresponding .box files, I use nekmerge and there comes my problem. I get the following error message: [loiseau at Quadstation-01 cylindre]$ ./nekmerge ascii or binary output ? (a/b): a Input new (output) file name: cylindre Input source .rea file name or press enter to continue: 1 Input source .rea file name or press enter to continue: 2 Input source .rea file name or press enter to continue: locglob: 1 1 1 324 locglob: 1 2 214 324 locglob: 2 1 289 324 locglob: 2 2 289 324 done locglob_lexico: 290 290 324 FACE ERROR: 5 3 108 5 Attached are all the .box and .rea files I have used. Could anyone give me a hint on how to solve this little problem ? Regards, Jean-Christophe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.rea URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2.rea URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: carre.box URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cylindre.box URL: From nek5000-users at lists.mcs.anl.gov Thu Apr 22 07:02:25 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 07:02:25 -0500 (CDT) Subject: [Nek5000-users] Periodic flow around sphere In-Reply-To: References: <4BCFFABA.6060703@kit.edu> Message-ID: Fred, Your other email was too large to make it onto the list. It appears that the issue is the following -- automatic timestep selection (i.e., dt > or = 0), doesn't appear to work with the projection acceleration (param 93, 94, 95 > 0). So either set param 12 < 0, such that dt = | param 12 |, or set p93-95 == 0. I'm pretty certain that will take care of the problem. (I almost invariably run with dt < 0...) Paul On Thu, 22 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > To be more precise - by nested, I really meant that there are > elements that overlap the same regions... this would be very > confusing to genmap/nek --- it's one of the cases for which we > don't currently have any checks (it's not easy in the general > case... though I think I might now have some ideas on how to > get at least _some_ type of checking in place) > > Paul > > > On Thu, 22 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> >> Hi Fred, when I view this in postx I get the impression that there >> are two nested meshes there... One associated with the sphere, the >> other looks like a std. periodic box ? (box first, sphere second) >> >> What tipped me off is that your number of elements is not divisible >> by 6, and that when I selected to plot face 5, some faces that are >> not part of the std. spherical mesh configuration showed up. >> >> Checking further... >> >> Paul >> >> >> On Thu, 22 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear NEKs, >>> >>> I'm trying to compute periodic channel flow around a sphere. The grid I >>> made with Prenek (SPHERICAL MESH). But the run is always crashing after >>> some timesteps. I tried with different meshes and configurations but it >>> never run through... >>> >>> I attached the .rea, .usr, SIZE and output files. >>> >>> Best, Fred >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Apr 22 07:08:24 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 07:08:24 -0500 (CDT) Subject: [Nek5000-users] Nekmerge question In-Reply-To: <4BD00D3C.4090809@gmail.com> References: <4BD00D3C.4090809@gmail.com> Message-ID: Jean-Christophe, One approach to merging is to use the pretex (tex-based prex) code. Basic steps are listed below, with entries indicated by "> " Paul Choose a Name for This Session: > s Beginning Session s 1 READ PREVIOUS PARAMETERS 2 TYPE IN NEW PARAMETERS 3 CONJ. HEAT TRANSFER MERGE Choose item: > 1 Enter name of previous session > s2 1 BUILD FROM FILE 2 ALTER PARAMETERS 3 SHOW PARAMETERS 4 BUILD INTERACTIVELY > 1 Choose item: Enter name of previous session (Default= s2.rea ) > s2 1 END ELEMENTS 2 MODIFY ELEMENT 3 GLOBAL REFINE 4 UP LEVEL 5 DOWN LEVEL 6 CURVE SIDES 7 DELETE ELEMENT 8 CEILING 9 REDRAW MESH 10 SET GRID 11 ZOOM 12 IMPORT MESH 13 IMPORT vtx MESH 14 IMPORT vtk MESH 15 REFLECT MESH 16 DEFINE OBJECT Choose item: > 12 input name of new .rea file s3 Would you like to displace existing elements in box? > n 1 END ELEMENTS 2 MODIFY ELEMENT 3 GLOBAL REFINE 4 UP LEVEL 5 DOWN LEVEL 6 CURVE SIDES 7 DELETE ELEMENT 8 CEILING 9 REDRAW MESH 10 SET GRID 11 ZOOM 12 IMPORT MESH 13 IMPORT vtx MESH 14 IMPORT vtk MESH 15 REFLECT MESH 16 DEFINE OBJECT Choose item: > 1 1 ACCEPT MATL,QVOL 2 SELECT ELEMENT 3 SELECT MATL [ 0] 4 SET MATL PROPS,Q 5 SHOW MATL PROPS,Q Choose item: > 1 1 ACCEPT B.C.'s 2 REVIEW/MODIFY Choose item: > 1 Curve side consistency check OK. 1 ACCEPT B.C.'s 2 REVIEW/MODIFY Choose item: > 1 Curve side consistency check OK. Generating Mesh Points for 840 Elements 1 EXIT 2 OUTPUT 3 DRIVE FORCE 4 INITIAL COND 5 INTEGRAL QUANTITY 6 OBJECT 7 ZOOM Choose item: > 1 Writing Parameters to file Deleting tmp.* files. On Thu, 22 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I know there already exists a thread having the same title dating back to > November 2009, but no one has answered to it yet. > I also have some question regarding nekmerge. > > I would like to mesh the cross-section of a cylindrical pipe. Using the > cylindrical version of genbox, I obviously get into troubles as soon as I > include the axis. > As a consequence, I would like to merge two meshes: > - a cartesian one in the vicinity of the axis > - a cylindrical one for the rest of the pipe > > Once I genboxed the corresponding .box files, I use nekmerge and there comes > my problem. I get the following error message: > > [loiseau at Quadstation-01 cylindre]$ ./nekmerge > ascii or binary output ? (a/b): > a > Input new (output) file name: > cylindre > Input source .rea file name or press enter to continue: > 1 > Input source .rea file name or press enter to continue: > 2 > Input source .rea file name or press enter to continue: > > locglob: 1 1 1 324 > locglob: 1 2 214 324 > locglob: 2 1 289 324 > locglob: 2 2 289 324 > done locglob_lexico: 290 290 324 > FACE ERROR: 5 3 108 5 > > Attached are all the .box and .rea files I have used. Could anyone give me a > hint on how to solve this little problem ? > > Regards, > > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Thu Apr 22 07:43:30 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 14:43:30 +0200 Subject: [Nek5000-users] Nekmerge question In-Reply-To: References: <4BD00D3C.4090809@gmail.com> Message-ID: <4BD04472.2010505@gmail.com> Thanks a lot for those tips. I assume that prex and prenek are the same, right ? In that case, I have some trouble when compiling prenek: mxm.f(54): (col. 13) remark: LOOP WAS VECTORIZED. gcc -c -DUNDERSCORE -Dr8 xdriver.c xdriver.c: In function ?TypeChar?: xdriver.c:759: attention : comparaison est toujours vraie en raison d'une gamme limit?e de type de donn?es ifort -o /home/loiseau/BricoNek/cylindre/prex prenek.o curve.o edit.o build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o xdriver.o -L/usr/X11R6/lib -lX11 -lm prenek.o: In function `intcnd_': prenek.f:(.text+0x408): relocation truncated to fit: R_X86_64_PC32 against symbol `ibasic_' defined in COMMON section in prenek.o prenek.f:(.text+0x410): relocation truncated to fit: R_X86_64_PC32 against symbol `ibasic_' defined in COMMON section in prenek.o prenek.o: In function `readln_': prenek.f:(.text+0x6c2): relocation truncated to fit: R_X86_64_PC32 against symbol `modes_' defined in COMMON section in prenek.o prenek.f:(.text+0x6fd): relocation truncated to fit: R_X86_64_32S against symbol `chaar_' defined in COMMON section in prenek.o prenek.f:(.text+0x759): relocation truncated to fit: R_X86_64_32S against symbol `chaar_' defined in COMMON section in prenek.o prenek.f:(.text+0x76b): relocation truncated to fit: R_X86_64_32S against symbol `chaar_' defined in COMMON section in prenek.o prenek.f:(.text+0x79e): relocation truncated to fit: R_X86_64_32S against symbol `chaar_' defined in COMMON section in prenek.o prenek.o: In function `drivef_': prenek.f:(.text+0x81d): relocation truncated to fit: R_X86_64_PC32 against symbol `fortrn_' defined in COMMON section in prenek.o prenek.f:(.text+0x838): relocation truncated to fit: R_X86_64_PC32 against symbol `logi_' defined in COMMON section in prenek.o prenek.f:(.text+0x8f6): relocation truncated to fit: R_X86_64_PC32 against symbol `modes_' defined in COMMON section in prenek.o prenek.f:(.text+0x931): additional relocation overflows omitted from the output make[1]: *** [prex] Erreur 1 make[1]: quittant le r?pertoire ? /home/loiseau/nek5_svn/trunk/tools/prenek ? make: *** [all] Erreur 1 Jean-Christophe From nek5000-users at lists.mcs.anl.gov Thu Apr 22 07:53:57 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 14:53:57 +0200 Subject: [Nek5000-users] Nekmerge question In-Reply-To: <4BD04472.2010505@gmail.com> References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> Message-ID: Please enable the big memory support in maketools (BIGMEM="true") and try again. Stefan On Apr 22, 2010, at 2:43 PM, nek5000-users at lists.mcs.anl.gov wrote: > Thanks a lot for those tips. > I assume that prex and prenek are the same, right ? > > In that case, I have some trouble when compiling prenek: > > mxm.f(54): (col. 13) remark: LOOP WAS VECTORIZED. > gcc -c -DUNDERSCORE -Dr8 xdriver.c > xdriver.c: In function ?TypeChar?: > xdriver.c:759: attention : comparaison est toujours vraie en raison d'une gamme limit?e de type de donn?es > ifort -o /home/loiseau/BricoNek/cylindre/prex prenek.o curve.o edit.o build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o xdriver.o -L/usr/X11R6/lib -lX11 -lm > prenek.o: In function `intcnd_': > prenek.f:(.text+0x408): relocation truncated to fit: R_X86_64_PC32 against symbol `ibasic_' defined in COMMON section in prenek.o > prenek.f:(.text+0x410): relocation truncated to fit: R_X86_64_PC32 against symbol `ibasic_' defined in COMMON section in prenek.o > prenek.o: In function `readln_': > prenek.f:(.text+0x6c2): relocation truncated to fit: R_X86_64_PC32 against symbol `modes_' defined in COMMON section in prenek.o > prenek.f:(.text+0x6fd): relocation truncated to fit: R_X86_64_32S against symbol `chaar_' defined in COMMON section in prenek.o > prenek.f:(.text+0x759): relocation truncated to fit: R_X86_64_32S against symbol `chaar_' defined in COMMON section in prenek.o > prenek.f:(.text+0x76b): relocation truncated to fit: R_X86_64_32S against symbol `chaar_' defined in COMMON section in prenek.o > prenek.f:(.text+0x79e): relocation truncated to fit: R_X86_64_32S against symbol `chaar_' defined in COMMON section in prenek.o > prenek.o: In function `drivef_': > prenek.f:(.text+0x81d): relocation truncated to fit: R_X86_64_PC32 against symbol `fortrn_' defined in COMMON section in prenek.o > prenek.f:(.text+0x838): relocation truncated to fit: R_X86_64_PC32 against symbol `logi_' defined in COMMON section in prenek.o > prenek.f:(.text+0x8f6): relocation truncated to fit: R_X86_64_PC32 against symbol `modes_' defined in COMMON section in prenek.o > prenek.f:(.text+0x931): additional relocation overflows omitted from the output > make[1]: *** [prex] Erreur 1 > make[1]: quittant le r?pertoire ? /home/loiseau/nek5_svn/trunk/tools/prenek ? > make: *** [all] Erreur 1 > > Jean-Christophe > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 22 07:52:05 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 14:52:05 +0200 Subject: [Nek5000-users] Nekmerge question In-Reply-To: References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> Message-ID: <4BD04675.6010201@gmail.com> Well, it did'nt change much. mxm.f(54): (col. 13) remark: LOOP WAS VECTORIZED. gcc -mcmodel=medium -c -DUNDERSCORE -Dr8 xdriver.c xdriver.c: In function ?TypeChar?: xdriver.c:759: warning: comparison is always true due to limited range of data type ifort -mcmodel=medium -o /home/loiseau/BricoNek/cylindre/prex prenek.o curve.o edit.o build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o xdriver.o -L/usr/X11R6/lib -lX11 -lm xdriver.o: In function `SetUpEnv': xdriver.c:(.text+0xec): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o xdriver.o: In function `advanceLine': xdriver.c:(.text+0x12d9): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o xdriver.o: In function `puts_': xdriver.c:(.text+0x1523): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o xdriver.c:(.text+0x155c): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o xdriver.o: In function `TypeChar': xdriver.c:(.text+0x17f9): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o): In function `for__message_catalog_close': for_diags_intel.c:(.text+0x17): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o): In function `for__io_return': for_diags_intel.c:(.text+0xb10): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) for_diags_intel.c:(.text+0xbd8): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) for_diags_intel.c:(.text+0xc29): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o): In function `for__issue_diagnostic': for_diags_intel.c:(.text+0xd58): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) for_diags_intel.c:(.text+0xdc0): additional relocation overflows omitted from the output make[1]: *** [prex] Erreur 1 make[1]: quittant le r?pertoire ? /home/loiseau/nek5_svn/trunk/tools/prenek ? make: *** [all] Erreur 1 From nek5000-users at lists.mcs.anl.gov Thu Apr 22 08:01:57 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 15:01:57 +0200 Subject: [Nek5000-users] Nekmerge question In-Reply-To: <4BD04675.6010201@gmail.com> References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> <4BD04675.6010201@gmail.com> Message-ID: Did you remove your old object files? Run 'maketools clean' to be sure. Stefan On Apr 22, 2010, at 2:52 PM, nek5000-users at lists.mcs.anl.gov wrote: > Well, it did'nt change much. > > mxm.f(54): (col. 13) remark: LOOP WAS VECTORIZED. > gcc -mcmodel=medium -c -DUNDERSCORE -Dr8 xdriver.c > xdriver.c: In function ?TypeChar?: > xdriver.c:759: warning: comparison is always true due to limited range of data type > ifort -mcmodel=medium -o /home/loiseau/BricoNek/cylindre/prex prenek.o curve.o edit.o build.o build1.o build2.o bound.o plot.o xinterface.o glomod.o legend.o vprops.o iolib.o subs.o zipper2.o postnek6.o screen.o revert.o crs.o mxm.o xdriver.o -L/usr/X11R6/lib -lX11 -lm > xdriver.o: In function `SetUpEnv': > xdriver.c:(.text+0xec): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o > xdriver.o: In function `advanceLine': > xdriver.c:(.text+0x12d9): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o > xdriver.o: In function `puts_': > xdriver.c:(.text+0x1523): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o > xdriver.c:(.text+0x155c): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o > xdriver.o: In function `TypeChar': > xdriver.c:(.text+0x17f9): relocation truncated to fit: R_X86_64_32S against symbol `Line' defined in COMMON section in xdriver.o > /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o): In function `for__message_catalog_close': > for_diags_intel.c:(.text+0x17): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) > /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o): In function `for__io_return': > for_diags_intel.c:(.text+0xb10): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) > for_diags_intel.c:(.text+0xbd8): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) > for_diags_intel.c:(.text+0xc29): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) > /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o): In function `for__issue_diagnostic': > for_diags_intel.c:(.text+0xd58): relocation truncated to fit: R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section in /opt/intel/Compiler/11.0/074/lib/intel64/libifcore.a(for_diags_intel.o) > for_diags_intel.c:(.text+0xdc0): additional relocation overflows omitted from the output > make[1]: *** [prex] Erreur 1 > make[1]: quittant le r?pertoire ? /home/loiseau/nek5_svn/trunk/tools/prenek ? > make: *** [all] Erreur 1 > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 22 07:56:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 14:56:49 +0200 Subject: [Nek5000-users] Nekmerge question In-Reply-To: References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> Message-ID: <4BD04791.2030503@gmail.com> Sure I did. It seems that when BIGMEM="true" I get errors only when using ifort. Things get different when using gfortran. JC From nek5000-users at lists.mcs.anl.gov Thu Apr 22 08:05:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 15:05:54 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: <2B4F00D0-AD60-4470-A1E4-FE4CE037A7DB@lav.mavt.ethz.ch> References: <1271851086.31181.46.camel@localhost.localdomain> <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> <1271860601.31181.62.camel@localhost.localdomain> <2B4F00D0-AD60-4470-A1E4-FE4CE037A7DB@lav.mavt.ethz.ch> Message-ID: <07C9E129-BE01-4E3C-842D-8E9EC7E7CD63@lav.mavt.ethz.ch> Frank, it seems like my first hunch was correct. [stefan at tetra ~]# mpif77 -showme ; echo $? sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored otherwise Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details 0 The SUN compiler returns a ZERO exit code even if you use unknown compiler flags. That's really stupid! Let me think about a fix for that. Stefan > > On Apr 21, 2010, at 4:36 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> On Wed, 2010-04-21 at 14:25 +0200, nek5000-users at lists.mcs.anl.gov >> wrote: >>> Ok I think what happens is the following: >>> >>> We need to detect which compilers are used by the MPI-wrappers. Depending on the MPI implementation there are some flags (e.g. -showme / -show) you can use to figure that out. >>> >>> MPICH doesn't know the flag -showme hence it is passed to the compiler (in your case sunf95). >>> The sun compiler says this is an unknown flag and returns a ZERO exit code. >>> This is weird if not to say wrong because you would assume that the right exit code should be NON-ZERO in this case! >>> >>> It looks like only the SUN compiler behaves wrong in this situation. >>> Unfortunately I don't have access to machine with MPICH/SUN so I cannot test my hypothesis. >> >> >>> >>> Stefan >>> >>> >>> On Apr 21, 2010, at 2:00 PM, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> What MPI implementation are you using? >>>> >>>> Stefan >>>> >>>> >>>> On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hello all, >>>>> >>>>> I am seeing the following error message when I use an mpif77 and mpicc >>>>> that use the Sun compilers. Everything is fine if in makenek F77=sunf95 >>>>> and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use >>>>> the Intel compilers. >>>>> >>>>> Cheers, >>>>> Frank >>>>> >>>>> >>>>> sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored >>>>> otherwise >>>>> Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details >>>>> WARNING: Cannot detect compiler specfic flags >>>>> echo - to promote REAL to 8 bytes >>>>> echo - to invoke preprocessor first >>>>> Please edit the makefile and specify the requested compiler flags in the >>>>> P variable! >>>>> >>>>> -- >>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>>> Technische Universit?t Wien (Technical University of Vienna) >>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>>> Mechanics and Heat Transfer) >>>>> Resselgasse 3 >>>>> 1040 Wien >>>>> Tel: +4315880132232 >>>>> Fax: +4315880132299 >>>>> Cell:+436765203470 >>>>> fmuldoo (skype) >>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 >> Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Apr 22 08:12:31 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 08:12:31 -0500 Subject: [Nek5000-users] Detected non-right-handed element.. In-Reply-To: References: Message-ID: <76b579d364d53e8c8a89f0de77362685.squirrel@webmail.uic.edu> Hi, I was having trouble with "non-right-handed element" warning for a BFS case. Then I tried running the example case "fs_2" with repo. version 491 and got the same error as given below. This works just fine with repo. verison 486. The code is compiled with GNU compiler. =========================================================================== WARNINGa: Detected non-right-handed element. Number 1 C1-4: -0.3000E+00 -0.3000E+00 0.0000E+00 0.0000E+00 =========================================================================== Find attached the logfile for your reference. Thanks, Harish On Wed, April 21, 2010 3:59 pm, nek5000-users at lists.mcs.anl.gov wrote: > > Shriram, > > Can you post or send a gzip'd copy of your .rea/.usr file? > > Thanks, > > Paul > > > On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello, >> >> In the latest repo (491), I get the following error : >> >> >> WARNINGb: Detected non-right-handed element. >> Number 1 V1-8: -0.2133E-01 -0.2133E-01 0.0000E+00 0.0000E+00 >> 0.9570E-03 0.9570E-03 0.9570E-03 0.9570E-03 >> >> call exitt: dying ... >> >> >> However, the version I was using previously (479) did not have any >> problem >> while compiling or during simulations. Any thoughts ? >> Thanks for any help.. >> >> Regards >> Shriram >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: logfile Type: application/octet-stream Size: 2801 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Thu Apr 22 08:12:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 15:12:48 +0200 Subject: [Nek5000-users] Nekmerge question In-Reply-To: <4BD04791.2030503@gmail.com> References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> <4BD04791.2030503@gmail.com> Message-ID: Yes, it seems like we're having a problem with the Intel compiler. Let me check into that. Stefan On Apr 22, 2010, at 2:56 PM, nek5000-users at lists.mcs.anl.gov wrote: > Sure I did. > It seems that when BIGMEM="true" I get errors only when using ifort. Things get different when using gfortran. > > JC > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 22 08:26:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 15:26:55 +0200 Subject: [Nek5000-users] Nekmerge question In-Reply-To: References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> <4BD04791.2030503@gmail.com> Message-ID: <298E357E-C9A3-470E-A689-645B59EDA75B@lav.mavt.ethz.ch> Ok I think I know a way to fix the Intel compiler problem. To compile prenek (prex) you need to enable the BIGMEM support so you have to use at least the medium memory model. However the Intel compilers wants you to link all Intel-Libs dynamically if you use another memory model than small. Just set F77= "ifort -shared-intel" and it should work! hth, Stefan On Apr 22, 2010, at 3:12 PM, nek5000-users at lists.mcs.anl.gov wrote: > Yes, it seems like we're having a problem with the Intel compiler. Let me check into that. > > Stefan > > > On Apr 22, 2010, at 2:56 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Sure I did. >> It seems that when BIGMEM="true" I get errors only when using ifort. Things get different when using gfortran. >> >> JC >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 22 09:11:26 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 09:11:26 -0500 (CDT) Subject: [Nek5000-users] Detected non-right-handed element.. In-Reply-To: <76b579d364d53e8c8a89f0de77362685.squirrel@webmail.uic.edu> References: <76b579d364d53e8c8a89f0de77362685.squirrel@webmail.uic.edu> Message-ID: Dear Group, Sorry about the non-right-handed element issue... It seems to now be fixed for ifort/pgf/gnu/ etc. if you download the latest repo. (Change was to connect2.f...) Paul On Thu, 22 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I was having trouble with "non-right-handed element" warning for a BFS > case. Then I tried running the example case "fs_2" with repo. version 491 > and got the same error as given below. This works just fine with repo. > verison 486. The code is compiled with GNU compiler. > > =========================================================================== > > WARNINGa: Detected non-right-handed element. > Number 1 C1-4: -0.3000E+00 -0.3000E+00 0.0000E+00 0.0000E+00 > =========================================================================== > > Find attached the logfile for your reference. > > Thanks, > > Harish > > > On Wed, April 21, 2010 3:59 pm, nek5000-users at lists.mcs.anl.gov wrote: >> >> Shriram, >> >> Can you post or send a gzip'd copy of your .rea/.usr file? >> >> Thanks, >> >> Paul >> >> >> On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello, >>> >>> In the latest repo (491), I get the following error : >>> >>> >>> WARNINGb: Detected non-right-handed element. >>> Number 1 V1-8: -0.2133E-01 -0.2133E-01 0.0000E+00 0.0000E+00 >>> 0.9570E-03 0.9570E-03 0.9570E-03 0.9570E-03 >>> >>> call exitt: dying ... >>> >>> >>> However, the version I was using previously (479) did not have any >>> problem >>> while compiling or during simulations. Any thoughts ? >>> Thanks for any help.. >>> >>> Regards >>> Shriram >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > From nek5000-users at lists.mcs.anl.gov Thu Apr 22 10:13:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 17:13:52 +0200 Subject: [Nek5000-users] Nekmerge question In-Reply-To: <298E357E-C9A3-470E-A689-645B59EDA75B@lav.mavt.ethz.ch> References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> <4BD04791.2030503@gmail.com> <298E357E-C9A3-470E-A689-645B59EDA75B@lav.mavt.ethz.ch> Message-ID: <4BD067B0.1030801@gmail.com> Now that I can use pretex, I still have a few questions. Everything is going as it should (according to your answer Paul) until I reach the boundary conditions stage. Instead of getting: 1 ACCEPT B.C.'s 2 REVIEW/MODIFY I get the following: *** MIDWAY BREAK MENU *** ABORT to write build data to file and exit SET B.C'S to continue 1 SET BCs 2 ABORT As I wanna join the two meshes, I assume that the correct boundary conditions should be E (element) in the .box files. Nevertheless, such BC does not appear when choosing SET BCs. Here is what I get: *** BOUNDARY CONDITION MENU *** Begin Inputting Fluid Boundary Conditions B.C.> 74 1 1 PERIODIC-AUTO 2 PERIODIC 3 WALL 4 VELOCITY 5 OUTFLOW 6 OUTFLOW/N 7 VELOCITY (LOCAL) 8 SYMMETRY 9 MOVING WALL 10 MELTING FRONT 11 SET ENTIRE LEVEL 12 ZOOM I suppose that this problem might perhaps come from the fact that I do not have the same number of faces on the joining borders of each mesh, or something more or less the same. Is there anything more-or-less easy I could do, or do I have to built the square mesh so that each edge/face for the two joining borders are the same ? Regards, Jean-Christophe PS: Attached are the .rea and .box files I have used again. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: carre.box URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cylindre.box URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: s1.rea URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: s2.rea URL: From nek5000-users at lists.mcs.anl.gov Thu Apr 22 10:25:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 10:25:44 -0500 (CDT) Subject: [Nek5000-users] Nekmerge question In-Reply-To: <4BD067B0.1030801@gmail.com> References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> <4BD04791.2030503@gmail.com> <298E357E-C9A3-470E-A689-645B59EDA75B@lav.mavt.ethz.ch> <4BD067B0.1030801@gmail.com> Message-ID: Hi Jean-Christophe, It should inherit the bcs from the originating meshes and it will replace any bcs on shared interfaces with E-E automatically. Very important that the meshes you are merging are compatible with conforming interfaces and no domain overlap --- the merge code does not check for these conditions. Paul On Thu, 22 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Now that I can use pretex, I still have a few questions. > Everything is going as it should (according to your answer Paul) until I > reach the boundary conditions stage. Instead of getting: > > 1 ACCEPT B.C.'s > 2 REVIEW/MODIFY > > I get the following: > > *** MIDWAY BREAK MENU *** > ABORT to write build data to file and exit > SET B.C'S to continue > 1 SET BCs 2 ABORT > > As I wanna join the two meshes, I assume that the correct boundary conditions > should be E (element) in the .box files. Nevertheless, such BC does not > appear when choosing SET BCs. Here is what I get: > > *** BOUNDARY CONDITION MENU *** > Begin Inputting Fluid Boundary Conditions > B.C.> 74 1 > > 1 PERIODIC-AUTO 2 PERIODIC 3 WALL > 4 VELOCITY 5 OUTFLOW 6 OUTFLOW/N > 7 VELOCITY (LOCAL) 8 SYMMETRY 9 MOVING WALL > 10 MELTING FRONT 11 SET ENTIRE LEVEL 12 ZOOM > I suppose that this problem might perhaps come from the fact that I do not > have the same number of faces on the joining borders of each mesh, or > something more or less the same. Is there anything more-or-less easy I could > do, or do I have to built the square mesh so that each edge/face for the two > joining borders are the same ? > > Regards, > > Jean-Christophe > > PS: Attached are the .rea and .box files I have used again. > From nek5000-users at lists.mcs.anl.gov Thu Apr 22 11:04:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 18:04:55 +0200 Subject: [Nek5000-users] Nekmerge question In-Reply-To: References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> <4BD04791.2030503@gmail.com> <298E357E-C9A3-470E-A689-645B59EDA75B@lav.mavt.ethz.ch> <4BD067B0.1030801@gmail.com> Message-ID: <4BD073A7.30007@gmail.com> No domain overlap is alrgiht, but I didn't know about the conforming interfaces. I'll pick a glance tomorow on how to get the locations of each edge from my outer mesh, and I'll mesh the inside one according to these locations. Thanks a lot. Jean-Christophe From nek5000-users at lists.mcs.anl.gov Thu Apr 22 19:20:12 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 02:20:12 +0200 Subject: [Nek5000-users] large CFL numbers Message-ID: <1271982012.6742.49.camel@localhost.localdomain> Hello all, I am wondering if there is any fully implicit scheme in NEK5000 that would allow the use of much larger CFL numbers. The question arises due to the different behavior of certain flows driven by surface tension gradients in contrast to bluff body or fully turbulent flows. Many surface tension driven flows have fluid motion with a time scale that is very large relative to the time scale based on the velocity and length scale of the system. In other words the Strouhal number is ~50X smaller than for bluff body flows. If using an explicit scheme for the convective terms, the result is that the time step is restricted by the stability constraints of the convection scheme to be ~50X smaller than is needed to accurately resolve the temporal scales of the flow. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Apr 22 19:21:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 22 Apr 2010 19:21:38 -0500 (CDT) Subject: [Nek5000-users] large CFL numbers In-Reply-To: <1271982012.6742.49.camel@localhost.localdomain> References: <1271982012.6742.49.camel@localhost.localdomain> Message-ID: Hi Frank, If you're constrained by the convective CFL (only) and not by, say, free-surface motion or capillary waves, etc., then you can use the characteristics scheme, which allows CFL of 2-5, say, vs. 0.5. IFCHAR T in the .rea file --- Look at the results in www.mcs.anl.gov/~fischer/users.pdf Characteristics is not working for free-surface flows but it should work for your stress-induced flows, I believe. Paul On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, I am wondering if there is any fully implicit scheme in NEK5000 that would allow the use of much larger CFL numbers. The question arises due to the different behavior of certain flows driven by surface tension gradients in contrast to bluff body or fully turbulent flows. Many surface tension driven flows have fluid motion with a time scale that is very large relative to the time scale based on the velocity and length scale of the system. In other words the Strouhal number is ~50X smaller than for bluff body flows. If using an explicit scheme for the convective terms, the result is that the time step is restricted by the stability constraints of the convection scheme to be ~50X smaller than is needed to accurately resolve the temporal scales of the flow. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:06:52 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:06:52 +0200 Subject: [Nek5000-users] compilation, large memory Message-ID: <1272024412.6742.54.camel@localhost.localdomain> Hello all, I am having a problem compiling on an x86_64 system. Smaller problems work fine. My SIZE file starts out with: parameter (ldim=3) parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) parameter (lxd=9*4,lyd=lxd,lzd=lxd) The error message is: /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): In function `mpirinitf_': setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv1_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv1_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv1_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv2_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv2_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against symbol `mpiprivc_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against symbol `mpiprivc_' defined in COMMON section in comm_mpi.o make: *** [nek5000] Error 1 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:08:47 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 07:08:47 -0500 (CDT) Subject: [Nek5000-users] compilation, large memory In-Reply-To: <1272024412.6742.54.camel@localhost.localdomain> References: <1272024412.6742.54.camel@localhost.localdomain> Message-ID: Hi Frank, Are you running in parallel? How many processors, and how many elements in the problem of interest? If you have, say, 120 elements, and are running on 4 processors, you can set lelt=30, which would reduce your per-processor-memory footprint by a factor of 4. Cheers, Paul On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, I am having a problem compiling on an x86_64 system. Smaller problems work fine. My SIZE file starts out with: parameter (ldim=3) parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) parameter (lxd=9*4,lyd=lxd,lzd=lxd) The error message is: /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): In function `mpirinitf_': setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv1_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv1_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv1_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv2_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against symbol `mpipriv2_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against symbol `mpiprivc_' defined in COMMON section in comm_mpi.o setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against symbol `mpiprivc_' defined in COMMON section in comm_mpi.o make: *** [nek5000] Error 1 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:09:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:09:09 +0200 Subject: [Nek5000-users] compilation, large memory In-Reply-To: <1272024412.6742.54.camel@localhost.localdomain> References: <1272024412.6742.54.camel@localhost.localdomain> Message-ID: You're exceeding the limits of the medium memory model! Are you sure you want to use a polynomial order of N=lx-1=23? Stefan On Apr 23, 2010, at 2:06 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I am having a problem compiling on an x86_64 system. Smaller problems > work fine. My SIZE file starts out with: > > parameter (ldim=3) > parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) > parameter (lxd=9*4,lyd=lxd,lzd=lxd) > > The error message is: > > /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 > -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek > -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o > /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o > bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o > gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o > prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o > mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o > subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o > navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o > byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o > makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o > jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o > jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o > jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o > jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o > jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o > /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): > In function `mpirinitf_': > setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against > symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against > symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > make: *** [nek5000] Error 1 > > > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:33:48 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:33:48 +0200 Subject: [Nek5000-users] visit 2.0beta and 1.12.2 problems on windows Message-ID: The windows version of visit 2.0beta and 1.12.2 cannot process the attached very simple binary file. The file is opened without complaints, but visit does recognize any variable, not even the grid coordinates. The file can be visualized without problems on linux and mac. Any idea what is causing the problem? Best, -Christos. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: channel0.f0001 Type: application/octet-stream Size: 128536 bytes Desc: channel0.f0001 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: channel.nek5000 Type: application/octet-stream Size: 126 bytes Desc: channel.nek5000 URL: From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:36:28 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:36:28 +0200 Subject: [Nek5000-users] compilation, large memory In-Reply-To: References: <1272024412.6742.54.camel@localhost.localdomain> Message-ID: <1272026188.6742.64.camel@localhost.localdomain> On Fri, 2010-04-23 at 07:08 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Are you running in parallel? How many processors, and how > many elements in the problem of interest? Hi Paul, I am using 72 elements and 8 processors. I reduced lelt to 72 and it works. In general, should lelt=(# elements)/(# processors)? Cheers, Frank > > If you have, say, 120 elements, and are running on 4 processors, > you can set lelt=30, which would reduce your per-processor-memory > footprint by a factor of 4. > > Cheers, > > Paul > > > On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > I am having a problem compiling on an x86_64 system. Smaller problems > work fine. My SIZE file starts out with: > > parameter (ldim=3) > parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) > parameter (lxd=9*4,lyd=lxd,lzd=lxd) > > The error message is: > > /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 > -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek > -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o > /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o > bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o > gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o > prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o > mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o > subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o > navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o > byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o > makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o > jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o > jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o > jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o > jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o > jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o > /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): > In function `mpirinitf_': > setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against > symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against > symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > make: *** [nek5000] Error 1 > > > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:37:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:37:29 +0200 Subject: [Nek5000-users] BLAS Message-ID: <1272026249.6742.67.camel@localhost.localdomain> Hello all, I notice that the BLAS libraries are the non-tuned ones and are also compiled using "-O0". Are they an unimportant part of the computational intensive parts of the code? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:36:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:36:34 +0200 Subject: [Nek5000-users] compilation, large memory In-Reply-To: <1272026188.6742.64.camel@localhost.localdomain> References: <1272024412.6742.54.camel@localhost.localdomain> <1272026188.6742.64.camel@localhost.localdomain> Message-ID: Frank, for lelt see here: http://nek5000.mcs.anl.gov/index.php/SIZEu Stefan On Apr 23, 2010, at 2:36 PM, nek5000-users at lists.mcs.anl.gov wrote: > On Fri, 2010-04-23 at 07:08 -0500, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Frank, >> >> Are you running in parallel? How many processors, and how >> many elements in the problem of interest? > > Hi Paul, > > I am using 72 elements and 8 processors. I reduced lelt to 72 and it > works. In general, should lelt=(# elements)/(# processors)? > > Cheers, > Frank > >> >> If you have, say, 120 elements, and are running on 4 processors, >> you can set lelt=30, which would reduce your per-processor-memory >> footprint by a factor of 4. >> >> Cheers, >> >> Paul >> >> >> On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >> >> I am having a problem compiling on an x86_64 system. Smaller problems >> work fine. My SIZE file starts out with: >> >> parameter (ldim=3) >> parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) >> parameter (lxd=9*4,lyd=lxd,lzd=lxd) >> >> The error message is: >> >> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium >> -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 >> -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek >> -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o >> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium >> -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o >> bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o >> gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o >> prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o >> mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o >> subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o >> navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o >> byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o >> makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o >> jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o >> jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o >> jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o >> jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o >> jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o >> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): >> In function `mpirinitf_': >> setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against >> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o >> setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against >> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o >> setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against >> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o >> setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against >> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o >> setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against >> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o >> setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against >> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o >> setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against >> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o >> make: *** [nek5000] Error 1 >> >> >> >> >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 >> Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:38:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:38:07 +0200 Subject: [Nek5000-users] BLAS In-Reply-To: <1272026249.6742.67.camel@localhost.localdomain> References: <1272026249.6742.67.camel@localhost.localdomain> Message-ID: <5885603C-3F62-4778-B594-51570C1DD13B@lav.mavt.ethz.ch> No during the computation we don't use _any_ BLAS routines. Only in the setup phase to compute some eigenvalues. Stefan On Apr 23, 2010, at 2:37 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I notice that the BLAS libraries are the non-tuned ones and are also > compiled using "-O0". Are they an unimportant part of the computational > intensive parts of the code? > > Cheers, > Frank > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:38:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 05:38:58 -0700 Subject: [Nek5000-users] visit 2.0beta and 1.12.2 problems on windows In-Reply-To: References: Message-ID: Hi Christos, I will pursue. Debugging things on Windows is hard for me (I will likely have to offload to another VisIt developer), so I won't be able to respond to this today. You generated the file on a Linux box, correct? (I'm looking at another problem with Frank where I think portability of binary files is biting us there too.) Best, Hank On Fri, Apr 23, 2010 at 5:33 AM, wrote: > The windows version of visit 2.0beta and 1.12.2 cannot process the attached > very simple binary file. The file is opened without complaints, but visit > does recognize any variable, not even the grid coordinates. > > > > The file can be visualized without problems on linux and mac. > > > > Any idea what is causing the problem? > > > > Best, > > -Christos. > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:41:17 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:41:17 +0200 Subject: [Nek5000-users] visit 2.0beta and 1.12.2 problems on windows In-Reply-To: References: Message-ID: Right, the file was generated on a linux system. -Christos. -----Original Message----- From: nek5000-users-bounces at lists.mcs.anl.gov [mailto:nek5000-users-bounces at lists.mcs.anl.gov] On Behalf Of nek5000-users at lists.mcs.anl.gov Sent: Friday, April 23, 2010 2:39 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] visit 2.0beta and 1.12.2 problems on windows Hi Christos, I will pursue. Debugging things on Windows is hard for me (I will likely have to offload to another VisIt developer), so I won't be able to respond to this today. You generated the file on a Linux box, correct? (I'm looking at another problem with Frank where I think portability of binary files is biting us there too.) Best, Hank On Fri, Apr 23, 2010 at 5:33 AM, wrote: > The windows version of visit 2.0beta and 1.12.2 cannot process the attached > very simple binary file. The file is opened without complaints, but visit > does recognize any variable, not even the grid coordinates. > > > > The file can be visualized without problems on linux and mac. > > > > Any idea what is causing the problem? > > > > Best, > > -Christos. > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:42:27 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 07:42:27 -0500 (CDT) Subject: [Nek5000-users] compilation, large memory In-Reply-To: <1272026188.6742.64.camel@localhost.localdomain> References: <1272024412.6742.54.camel@localhost.localdomain> <1272026188.6742.64.camel@localhost.localdomain> Message-ID: Yes -- lelt = nel/P On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > On Fri, 2010-04-23 at 07:08 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > Are you running in parallel? How many processors, and how > many elements in the problem of interest? Hi Paul, I am using 72 elements and 8 processors. I reduced lelt to 72 and it works. In general, should lelt=(# elements)/(# processors)? Cheers, Frank > > If you have, say, 120 elements, and are running on 4 processors, > you can set lelt=30, which would reduce your per-processor-memory > footprint by a factor of 4. > > Cheers, > > Paul > > > On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > I am having a problem compiling on an x86_64 system. Smaller problems > work fine. My SIZE file starts out with: > > parameter (ldim=3) > parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) > parameter (lxd=9*4,lyd=lxd,lzd=lxd) > > The error message is: > > /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 > -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek > -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o > /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o > bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o > gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o > prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o > mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o > subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o > navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o > byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o > makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o > jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o > jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o > jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o > jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o > jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o > /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): > In function `mpirinitf_': > setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against > symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against > symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against > symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > make: *** [nek5000] Error 1 > > > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:46:23 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:46:23 +0200 Subject: [Nek5000-users] compilation, large memory In-Reply-To: References: <1272024412.6742.54.camel@localhost.localdomain> <1272026188.6742.64.camel@localhost.localdomain> Message-ID: <1272026783.6742.72.camel@localhost.localdomain> Hi Stefan, It is not clear what NELGT in the definition of LELT at this link is (it is not defined anywhere on the site). Maximum number of local elements for T-mesh (>= int(NELGT/NP) + 1) Cheers, Frank On Fri, 2010-04-23 at 14:36 +0200, nek5000-users at lists.mcs.anl.gov wrote: > Frank, > > for lelt see here: > http://nek5000.mcs.anl.gov/index.php/SIZEu > > Stefan > > > On Apr 23, 2010, at 2:36 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > On Fri, 2010-04-23 at 07:08 -0500, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Frank, > >> > >> Are you running in parallel? How many processors, and how > >> many elements in the problem of interest? > > > > Hi Paul, > > > > I am using 72 elements and 8 processors. I reduced lelt to 72 and it > > works. In general, should lelt=(# elements)/(# processors)? > > > > Cheers, > > Frank > > > >> > >> If you have, say, 120 elements, and are running on 4 processors, > >> you can set lelt=30, which would reduce your per-processor-memory > >> footprint by a factor of 4. > >> > >> Cheers, > >> > >> Paul > >> > >> > >> On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hello all, > >> > >> I am having a problem compiling on an x86_64 system. Smaller problems > >> work fine. My SIZE file starts out with: > >> > >> parameter (ldim=3) > >> parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) > >> parameter (lxd=9*4,lyd=lxd,lzd=lxd) > >> > >> The error message is: > >> > >> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > >> -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 > >> -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek > >> -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o > >> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > >> -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o > >> bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o > >> gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o > >> prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o > >> mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o > >> subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o > >> navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o > >> byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o > >> makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o > >> jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o > >> jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o > >> jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o > >> jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o > >> jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o > >> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): > >> In function `mpirinitf_': > >> setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against > >> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > >> setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against > >> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > >> setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against > >> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > >> setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against > >> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > >> setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against > >> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > >> setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against > >> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > >> setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against > >> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > >> make: *** [nek5000] Error 1 > >> > >> > >> > >> > >> -- > >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >> Technische Universit?t Wien (Technical University of Vienna) > >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >> Mechanics and Heat Transfer) > >> Resselgasse 3 > >> 1040 Wien > >> Tel: +4315880132232 > >> Fax: +4315880132299 > >> Cell:+436765203470 > >> fmuldoo (skype) > >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:47:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:47:34 +0200 Subject: [Nek5000-users] compilation, large memory In-Reply-To: <1272026783.6742.72.camel@localhost.localdomain> References: <1272024412.6742.54.camel@localhost.localdomain> <1272026188.6742.64.camel@localhost.localdomain> <1272026783.6742.72.camel@localhost.localdomain> Message-ID: <820C8CAE-26B6-444D-BA15-FDB28A2C8AB0@lav.mavt.ethz.ch> NELGT is the actual total number of elements where LELG is an upper limit for NELGT. So if: LELT >= int(LELG/NP) + 1 you're ok for sure! btw: I think the wiki is open for everybody. Please try to improve it together with us! hth, Stefan On Apr 23, 2010, at 2:46 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > It is not clear what NELGT in the definition of LELT at this link is (it > is not defined anywhere on the site). > > Maximum number of local elements for T-mesh (>= int(NELGT/NP) + 1) > > Cheers, > Frank > > > > > On Fri, 2010-04-23 at 14:36 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> Frank, >> >> for lelt see here: >> http://nek5000.mcs.anl.gov/index.php/SIZEu >> >> Stefan >> >> >> On Apr 23, 2010, at 2:36 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> On Fri, 2010-04-23 at 07:08 -0500, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Hi Frank, >>>> >>>> Are you running in parallel? How many processors, and how >>>> many elements in the problem of interest? >>> >>> Hi Paul, >>> >>> I am using 72 elements and 8 processors. I reduced lelt to 72 and it >>> works. In general, should lelt=(# elements)/(# processors)? >>> >>> Cheers, >>> Frank >>> >>>> >>>> If you have, say, 120 elements, and are running on 4 processors, >>>> you can set lelt=30, which would reduce your per-processor-memory >>>> footprint by a factor of 4. >>>> >>>> Cheers, >>>> >>>> Paul >>>> >>>> >>>> On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hello all, >>>> >>>> I am having a problem compiling on an x86_64 system. Smaller problems >>>> work fine. My SIZE file starts out with: >>>> >>>> parameter (ldim=3) >>>> parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) >>>> parameter (lxd=9*4,lyd=lxd,lzd=lxd) >>>> >>>> The error message is: >>>> >>>> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium >>>> -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 >>>> -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek >>>> -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o >>>> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium >>>> -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o >>>> bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o >>>> gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o >>>> prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o >>>> mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o >>>> subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o >>>> navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o >>>> byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o >>>> makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o >>>> jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o >>>> jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o >>>> jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o >>>> jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o >>>> jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o >>>> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): >>>> In function `mpirinitf_': >>>> setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against >>>> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o >>>> setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against >>>> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o >>>> setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against >>>> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o >>>> setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against >>>> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o >>>> setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against >>>> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o >>>> setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against >>>> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o >>>> setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against >>>> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o >>>> make: *** [nek5000] Error 1 >>>> >>>> >>>> >>>> >>>> -- >>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>> Technische Universit?t Wien (Technical University of Vienna) >>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>> Mechanics and Heat Transfer) >>>> Resselgasse 3 >>>> 1040 Wien >>>> Tel: +4315880132232 >>>> Fax: +4315880132299 >>>> Cell:+436765203470 >>>> fmuldoo (skype) >>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 23 08:04:33 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 15:04:33 +0200 Subject: [Nek5000-users] compilation, large memory In-Reply-To: <820C8CAE-26B6-444D-BA15-FDB28A2C8AB0@lav.mavt.ethz.ch> References: <1272024412.6742.54.camel@localhost.localdomain> <1272026188.6742.64.camel@localhost.localdomain> <1272026783.6742.72.camel@localhost.localdomain> <820C8CAE-26B6-444D-BA15-FDB28A2C8AB0@lav.mavt.ethz.ch> Message-ID: <1272027873.6742.79.camel@localhost.localdomain> Hi Stefan, Perhaps someone would need to create an account for me for the wiki? Logging in with my Nek5000-users account doesn't work. Cheers, Frank On Fri, 2010-04-23 at 14:47 +0200, nek5000-users at lists.mcs.anl.gov wrote: > NELGT is the actual total number of elements where LELG is an upper limit for NELGT. > So if: > > LELT >= int(LELG/NP) + 1 > > you're ok for sure! > > btw: I think the wiki is open for everybody. Please try to improve it together with us! > > hth, > Stefan > > > On Apr 23, 2010, at 2:46 PM, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Stefan, > > > > It is not clear what NELGT in the definition of LELT at this link is (it > > is not defined anywhere on the site). > > > > Maximum number of local elements for T-mesh (>= int(NELGT/NP) + 1) > > > > Cheers, > > Frank > > > > > > > > > > On Fri, 2010-04-23 at 14:36 +0200, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Frank, > >> > >> for lelt see here: > >> http://nek5000.mcs.anl.gov/index.php/SIZEu > >> > >> Stefan > >> > >> > >> On Apr 23, 2010, at 2:36 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> On Fri, 2010-04-23 at 07:08 -0500, nek5000-users at lists.mcs.anl.gov > >>> wrote: > >>>> Hi Frank, > >>>> > >>>> Are you running in parallel? How many processors, and how > >>>> many elements in the problem of interest? > >>> > >>> Hi Paul, > >>> > >>> I am using 72 elements and 8 processors. I reduced lelt to 72 and it > >>> works. In general, should lelt=(# elements)/(# processors)? > >>> > >>> Cheers, > >>> Frank > >>> > >>>> > >>>> If you have, say, 120 elements, and are running on 4 processors, > >>>> you can set lelt=30, which would reduce your per-processor-memory > >>>> footprint by a factor of 4. > >>>> > >>>> Cheers, > >>>> > >>>> Paul > >>>> > >>>> > >>>> On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hello all, > >>>> > >>>> I am having a problem compiling on an x86_64 system. Smaller problems > >>>> work fine. My SIZE file starts out with: > >>>> > >>>> parameter (ldim=3) > >>>> parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) > >>>> parameter (lxd=9*4,lyd=lxd,lzd=lxd) > >>>> > >>>> The error message is: > >>>> > >>>> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > >>>> -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 > >>>> -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek > >>>> -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o > >>>> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium > >>>> -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o > >>>> bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o > >>>> gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o > >>>> prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o > >>>> mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o > >>>> subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o > >>>> navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o > >>>> byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o > >>>> makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o > >>>> jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o > >>>> jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o > >>>> jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o > >>>> jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o > >>>> jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o > >>>> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): > >>>> In function `mpirinitf_': > >>>> setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against > >>>> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > >>>> setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against > >>>> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > >>>> setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against > >>>> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o > >>>> setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against > >>>> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > >>>> setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against > >>>> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o > >>>> setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against > >>>> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > >>>> setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against > >>>> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o > >>>> make: *** [nek5000] Error 1 > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>>> Technische Universit?t Wien (Technical University of Vienna) > >>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>>> Mechanics and Heat Transfer) > >>>> Resselgasse 3 > >>>> 1040 Wien > >>>> Tel: +4315880132232 > >>>> Fax: +4315880132299 > >>>> Cell:+436765203470 > >>>> fmuldoo (skype) > >>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>>> > >>>> _______________________________________________ > >>>> Nek5000-users mailing list > >>>> Nek5000-users at lists.mcs.anl.gov > >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>>> _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >>> -- > >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering > >>> Technische Universit?t Wien (Technical University of Vienna) > >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > >>> Mechanics and Heat Transfer) > >>> Resselgasse 3 > >>> 1040 Wien > >>> Tel: +4315880132232 > >>> Fax: +4315880132299 > >>> Cell:+436765203470 > >>> fmuldoo (skype) > >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > >>> > >>> _______________________________________________ > >>> Nek5000-users mailing list > >>> Nek5000-users at lists.mcs.anl.gov > >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > >> > >> _______________________________________________ > >> Nek5000-users mailing list > >> Nek5000-users at lists.mcs.anl.gov > >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -- > > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > > Technische Universit?t Wien (Technical University of Vienna) > > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > > Mechanics and Heat Transfer) > > Resselgasse 3 > > 1040 Wien > > Tel: +4315880132232 > > Fax: +4315880132299 > > Cell:+436765203470 > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Apr 23 08:03:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 15:03:53 +0200 Subject: [Nek5000-users] compilation, large memory In-Reply-To: <1272027873.6742.79.camel@localhost.localdomain> References: <1272024412.6742.54.camel@localhost.localdomain> <1272026188.6742.64.camel@localhost.localdomain> <1272026783.6742.72.camel@localhost.localdomain> <820C8CAE-26B6-444D-BA15-FDB28A2C8AB0@lav.mavt.ethz.ch> <1272027873.6742.79.camel@localhost.localdomain> Message-ID: <9D768058-43D6-417A-BE5F-297DDB2E18C8@lav.mavt.ethz.ch> You cannot crate an account? Let me check ... Stefan On Apr 23, 2010, at 3:04 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Stefan, > > Perhaps someone would need to create an account for me for the wiki? > Logging in with my Nek5000-users account doesn't work. > > Cheers, > Frank > > > On Fri, 2010-04-23 at 14:47 +0200, nek5000-users at lists.mcs.anl.gov > wrote: >> NELGT is the actual total number of elements where LELG is an upper limit for NELGT. >> So if: >> >> LELT >= int(LELG/NP) + 1 >> >> you're ok for sure! >> >> btw: I think the wiki is open for everybody. Please try to improve it together with us! >> >> hth, >> Stefan >> >> >> On Apr 23, 2010, at 2:46 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Stefan, >>> >>> It is not clear what NELGT in the definition of LELT at this link is (it >>> is not defined anywhere on the site). >>> >>> Maximum number of local elements for T-mesh (>= int(NELGT/NP) + 1) >>> >>> Cheers, >>> Frank >>> >>> >>> >>> >>> On Fri, 2010-04-23 at 14:36 +0200, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Frank, >>>> >>>> for lelt see here: >>>> http://nek5000.mcs.anl.gov/index.php/SIZEu >>>> >>>> Stefan >>>> >>>> >>>> On Apr 23, 2010, at 2:36 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> On Fri, 2010-04-23 at 07:08 -0500, nek5000-users at lists.mcs.anl.gov >>>>> wrote: >>>>>> Hi Frank, >>>>>> >>>>>> Are you running in parallel? How many processors, and how >>>>>> many elements in the problem of interest? >>>>> >>>>> Hi Paul, >>>>> >>>>> I am using 72 elements and 8 processors. I reduced lelt to 72 and it >>>>> works. In general, should lelt=(# elements)/(# processors)? >>>>> >>>>> Cheers, >>>>> Frank >>>>> >>>>>> >>>>>> If you have, say, 120 elements, and are running on 4 processors, >>>>>> you can set lelt=30, which would reduce your per-processor-memory >>>>>> footprint by a factor of 4. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> On Fri, 23 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>>> Hello all, >>>>>> >>>>>> I am having a problem compiling on an x86_64 system. Smaller problems >>>>>> work fine. My SIZE file starts out with: >>>>>> >>>>>> parameter (ldim=3) >>>>>> parameter (lx1=6*4,ly1=lx1,lz1=lx1,lelt=120,lelv=lelt) >>>>>> parameter (lxd=9*4,lyd=lxd,lzd=lxd) >>>>>> >>>>>> The error message is: >>>>>> >>>>>> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium >>>>>> -shared-intel -c -O2 -r8 -fpconstant -fpp -DMPI -DLONGINT8 >>>>>> -I/home/fmuldoo/programs/nek5000/nek5/trunk/nek >>>>>> -I/data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel /data/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim7/AR-.66-RE-1800-PR-04.0-dt-6.0e-5-time-006.0-grid-3-Intel/delet.f -o delet.o >>>>>> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/bin/mpif77 -mcmodel=medium >>>>>> -shared-intel -o nek5000 delet.o drive.o drive1.o drive2.o plan4.o >>>>>> bdry.o coef.o conduct.o connect1.o connect2.o dssum.o edgec.o eigsolv.o >>>>>> gauss.o genxyz.o navier1.o navier0.o navier2.o navier3.o navier4.o >>>>>> prepost.o speclib.o map2.o turb.o mvmesh.o ic.o ssolv.o planx.o math.o >>>>>> mxm_wrapper.o hmholtz.o gfdm_par.o gfdm_op.o gfdm_solve.o subs1.o >>>>>> subs2.o genbox.o gmres.o hsmg.o convect.o induct.o perturb.o navier5.o >>>>>> navier6.o navier7.o navier8.o fast3d.o fasts.o calcz.o byte.o chelpers.o >>>>>> byte_mpi.o postpro.o cvode_driver.o cvode_aux.o setprop.o qthermal.o >>>>>> makeq.o papi.o ssygv.o dsygv.o mxm_std.o blas.o comm_mpi.o jl2_gs.o >>>>>> jl2_sort.o jl2_sarray_transfer.o jl2_sarray_sort.o jl2_gs_local.o >>>>>> jl2_crystal.o jl2_comm.o jl2_tensor.o jl2_fail.o jl2_fcrystal.o >>>>>> jl_tuple_list.o jl_transfer.o jl_sort.o jl_fcrystal.o jl_errmem.o >>>>>> jl_crystal.o jl_findpts.o jl_pfindpt.o jl_tensor.o jl_findpt.o jl_poly.o >>>>>> jl2_sparse_cholesky.o jl2_xxt.o jl2_fcrs.o >>>>>> /home/fmuldoo/programs/mpich2-1.2.1p1-intel/lib/libmpich.a(setbotf.o): >>>>>> In function `mpirinitf_': >>>>>> setbotf.f:(.text+0xd): relocation truncated to fit: R_X86_64_32 against >>>>>> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o >>>>>> setbotf.f:(.text+0x12): relocation truncated to fit: R_X86_64_32 against >>>>>> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o >>>>>> setbotf.f:(.text+0x17): relocation truncated to fit: R_X86_64_32 against >>>>>> symbol `mpipriv1_' defined in COMMON section in comm_mpi.o >>>>>> setbotf.f:(.text+0x1c): relocation truncated to fit: R_X86_64_32 against >>>>>> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o >>>>>> setbotf.f:(.text+0x22): relocation truncated to fit: R_X86_64_32 against >>>>>> symbol `mpipriv2_' defined in COMMON section in comm_mpi.o >>>>>> setbotf.f:(.text+0x28): relocation truncated to fit: R_X86_64_32 against >>>>>> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o >>>>>> setbotf.f:(.text+0x34): relocation truncated to fit: R_X86_64_32 against >>>>>> symbol `mpiprivc_' defined in COMMON section in comm_mpi.o >>>>>> make: *** [nek5000] Error 1 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>>>> Technische Universit?t Wien (Technical University of Vienna) >>>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>>>> Mechanics and Heat Transfer) >>>>>> Resselgasse 3 >>>>>> 1040 Wien >>>>>> Tel: +4315880132232 >>>>>> Fax: +4315880132299 >>>>>> Cell:+436765203470 >>>>>> fmuldoo (skype) >>>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>>>> >>>>>> _______________________________________________ >>>>>> Nek5000-users mailing list >>>>>> Nek5000-users at lists.mcs.anl.gov >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>>> _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>> -- >>>>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>>>> Technische Universit?t Wien (Technical University of Vienna) >>>>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>>>> Mechanics and Heat Transfer) >>>>> Resselgasse 3 >>>>> 1040 Wien >>>>> Tel: +4315880132232 >>>>> Fax: +4315880132299 >>>>> Cell:+436765203470 >>>>> fmuldoo (skype) >>>>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 23 07:55:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 14:55:29 +0200 Subject: [Nek5000-users] WIKI - user contributions are welcome Message-ID: <0A28B009-2A01-47C6-9EC8-971B94C43C97@lav.mavt.ethz.ch> Dear NEK Users, some time ago we started to come up with a Wiki where you can find some details about the code and other related stuff. However the Wiki is far from being complete and a lot of important things are missing. We're a growing community and it would be great to improve/extend (new tutorials, FAQ, etc.) the Wiki together with your help! To get write access just send a registration request to nek5000-developers at lists.mcs.anl.gov subject: WIKI registration request INCLUDING your email address (the one you used to subscribe to the nek5000-user mailing list). We're looking forward to your contribution. Cheers, Stefan & Paul From nek5000-users at lists.mcs.anl.gov Fri Apr 23 10:23:19 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 23 Apr 2010 20:53:19 +0530 Subject: [Nek5000-users] [*] WIKI - user contributions are welcome In-Reply-To: <0A28B009-2A01-47C6-9EC8-971B94C43C97@lav.mavt.ethz.ch> References: <0A28B009-2A01-47C6-9EC8-971B94C43C97@lav.mavt.ethz.ch> Message-ID: <4BD1BB67.9080809@iitk.ac.in> On 04/23/2010 06:25 PM, nek5000-users at lists.mcs.anl.gov wrote: > Dear NEK Users, > > some time ago we started to come up with a Wiki where you can find some details about the code and other related stuff. However the Wiki is far from being complete and a lot of important things are missing. > > We're a growing community and it would be great to improve/extend (new tutorials, FAQ, etc.) the Wiki together with your help! > > To get write access just send a registration request to > > nek5000-developers at lists.mcs.anl.gov > subject: WIKI registration request > > INCLUDING your email address (the one you used to subscribe to the nek5000-user mailing list). > > We're looking forward to your contribution. > > > Cheers, > Stefan& Paul > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > Dear Stefan and Paul, As a user, I found the wiki (and the mailing lists) to be of immense help and I would like to thank you for getting it up to this stage. I particularly find the format quite pleasing. I have nothing much to add really (am still quite new to nek5000), but would be glad to add something once I become more familiar with the code. Some examples/tutorials for some simple cases maybe? (although so far, I myself have modified the examples provided with nek to get what I want). Regards, Mani chandra From nek5000-users at lists.mcs.anl.gov Sun Apr 25 10:05:09 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 25 Apr 2010 11:05:09 -0400 Subject: [Nek5000-users] Residuals for post-processing In-Reply-To: References: <4BCEF889.1050105@vt.edu> Message-ID: <4BD45A25.4040005@vt.edu> Hi, this is what I added to usrchk: --- include 'GMRES' if (istep.gt.0) then call outpost(vx,vy,vz,res,t,'res') call exitti('quit in gmres$',n) endif --- Unfortunately, this causes the code to crash whenever outpost is called: --- 120 1.00000E-06 8.11690E-04 5.58247E-01 1.45400E-03 1 Divergence 1 U-Pres gmres: 120 8.1169E-04 1.0000E-06 5.5825E-01 2.8286E+00 8.0148E+00 1 DNORM, DIVEX 0.35002708528548815 8.11690205515358640E-004 1 5.0000E-03 8.3137E+00 Fluid done filt amp 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0125 0.0500 filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.9875 0.9500 ./nek: line 7: 11765 Segmentation fault (core dumped) ./nek5000 real 0m27.297s user 0m9.348s sys 0m1.124s --- I tried with pr instead of res, that works. Is it possible that res is not an array but a single number? Where are the residuals for velocity and passive scalars stored? I added the divergence procedure to the outflow, there is no back flow. The problem is not that the simulation blows up (at least for the time steps I am doing), it is that the pressure residuals don't fall below the specified limit when I increase lx1. This is for both PN/PN-2 and PN/PN and not a function of dt. Thanks, Markus nek5000-users at lists.mcs.anl.gov wrote: > > Hi Markus, > > pressure residuals are in gmres > > You could output them via: > > call outpost(x,y,z,res,t,'res') > > where x,y,z,t are arrays of your choice and res > is the array you want to look at. > > Nek will convert the res mesh to the velocity mesh > if needed. I usually follow such a call with > > call exitti('quit in gmres$',n) > > because prepost() uses some scratch common blocks > that are potentially shared with the calling routine > (not in the case of gmres, I think...) -- so data might be corrupted > after such a call. The idea of > prepost was to be called in between timesteps, when > such memory re-use would be admissable. The alternative > would be to define your own storage in a common block, > save the residuals to this locale, then loop through > calls to outpost in userchk afterwards... I've done > that in the past. > > All this being said, I'm not 100% certain that the > iterative solvers is the place to look for the difficulty. > Most problems arise from spatial resolution issues...or > temporal stability problems. The latter can be identified > by drastic reduction in dt. > > What exactly is blowing up for you? > > Paul > > > On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> I'd like to save the residuals for the pressure iterations (PN/PN-2 as >> well as PN/PN) into a scalar variable (scalar 0, instead of >> temperature say) for each grid point in order to see where my solution >> diverges. >> Is there a way to add something to the .usr file to do that? I >> couldn't find the variable in the code and also wouldn't know how to >> save something from the lx2=lx1-2 grid onto the lx1 grid. >> Would this also be possible with the velocity residuals? >> >> Thanks, >> Markus >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > uuuu > c----------------------------------------------------------------------- > subroutine uzawa_gmres(res,h1,h2,h2inv,intype,iter) > > c Solve the pressure equation by right-preconditioned c GMRES > iteration. > c intype = 0 (steady) > c intype = 1 (explicit) > c intype = -1 (implicit) > > include 'SIZE' > include 'TOTAL' > include 'GMRES' > common /ctolpr/ divex > common /cprint/ ifprint > logical ifprint > real res (lx2*ly2*lz2*lelv) > real h1 (lx1,ly1,lz1,lelv) > real h2 (lx1,ly1,lz1,lelv) > real h2inv(lx1,ly1,lz1,lelv) > > common /scrmg/ wp (lx2,ly2,lz2,lelv) > > common /ctmp0/ wk1(lgmres),wk2(lgmres) > common /cgmres1/ y(lgmres) > > real alpha, l, temp > integer j,m > c > logical iflag > save iflag > data iflag /.false./ > real norm_fac > save norm_fac > c > real*8 etime1,dnekclock > c > if(.not.iflag) then > iflag=.true. > call uzawa_gmres_split0(ml,mu,bm2,bm2inv,nx2*ny2*nz2*nelv) > norm_fac = 1./sqrt(volvm2) > endif > c > etime1 = dnekclock() > etime_p = 0. > divex = 0. > iter = 0 > m = lgmres > c > call chktcg2(tolps,res,iconv) > if (param(21).gt.0.and.tolps.gt.abs(param(21))) > $ tolps = abs(param(21)) > c if (param(21).lt.0) tolps = abs(param(21)) > if (istep.eq.0) tolps = 1.e-4 > tolpss = tolps > c > ntot2 = nx2*ny2*nz2*nelv > c > iconv = 0 > call rzero(x,ntot2) > > do while(iconv.eq.0.and.iter.lt.100) > > if(iter.eq.0) then > ! -1 > call col3(r,ml,res,ntot2) ! r = L res > c call copy(r,res,ntot2) > else > !update residual > call copy(r,res,ntot2) ! r = res > call cdabdtp(w,x,h1,h2,h2inv,intype) ! w = A x > call add2s2(r,w,-1.,ntot2) ! r = r - w > ! -1 > call col2(r,ml,ntot2) ! r = L r > endif > ! ______ > gamma(1) = sqrt(glsc2(r,r,ntot2)) ! gamma = \/ (r,r) > ! 1 > if(iter.eq.0) then > div0 = gamma(1)*norm_fac > if (param(21).lt.0) tolpss=abs(param(21))*div0 > endif > > !check for lucky convergence > rnorm = 0. > if(gamma(1) .eq. 0.) goto 9000 > temp = 1./gamma(1) > call cmult2(v(1,1),r,temp,ntot2) ! v = r / gamma > ! 1 1 > do j=1,m > iter = iter+1 > ! -1 > call col3(w,mu,v(1,j),ntot2) ! w = U v > ! j > > etime2 = dnekclock() > if(param(43).eq.1) then > call uzprec(z(1,j),w,h1,h2,intype,wp) > else ! -1 > call hsmg_solve(z(1,j),w) ! z = M w > endif > etime_p = etime_p + dnekclock()-etime2 > > call cdabdtp(w,z(1,j), ! w = A z > $ h1,h2,h2inv,intype) ! j > > ! -1 > call col2(w,ml,ntot2) ! w = L w > > c !modified Gram-Schmidt > c do i=1,j > c h(i,j)=glsc2(w,v(1,i),ntot2) ! h = (w,v ) > c ! i,j i > c call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v > c enddo ! i,j i > > > c 2-PASS GS, 1st pass: > > do i=1,j > h(i,j)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) > enddo ! i,j i > > call gop(h(1,j),wk1,'+ ',j) ! sum over P procs > > do i=1,j > call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v > enddo ! i,j i > > > c 2-PASS GS, 2nd pass: > c > c do i=1,j > c wk1(i)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) > c enddo ! i,j i > c ! > c call gop(wk1,wk2,'+ ',j) ! sum over P procs > c > c do i=1,j > c call add2s2(w,v(1,i),-wk1(i),ntot2)! w = w - h v > c h(i,j) = h(i,j) + wk1(i) ! i,j i > c enddo > > > !apply Givens rotations to new column > do i=1,j-1 > temp = h(i,j) > h(i ,j)= c(i)*temp + s(i)*h(i+1,j) > h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) > enddo > ! ______ > alpha = sqrt(glsc2(w,w,ntot2)) ! alpha = \/ (w,w) > rnorm = 0. > if(alpha.eq.0.) goto 900 !converged > l = sqrt(h(j,j)*h(j,j)+alpha*alpha) > temp = 1./l > c(j) = h(j,j) * temp > s(j) = alpha * temp > h(j,j) = l > gamma(j+1) = -s(j) * gamma(j) > gamma(j) = c(j) * gamma(j) > > c call outmat(h,m,j,' h ',j) > > rnorm = abs(gamma(j+1))*norm_fac > ratio = rnorm/div0 > if (ifprint.and.nid.eq.0) > $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep > 66 format(i5,1p4e12.5,i8,' Divergence') > > #ifndef TST_WSCAL > if (rnorm .lt. tolpss) goto 900 !converged > #else > if (iter.gt.param(151)-1) goto 900 > #endif > if (j.eq.m) goto 1000 !not converged, restart > > temp = 1./alpha > call cmult2(v(1,j+1),w,temp,ntot2) ! v = w / alpha > ! j+1 > enddo > 900 iconv = 1 > 1000 continue > !back substitution > ! -1 > !c = H gamma > do k=j,1,-1 > temp = gamma(k) > do i=j,k+1,-1 > temp = temp - h(k,i)*c(i) > enddo > c(k) = temp/h(k,k) > enddo > !sum up Arnoldi vectors > do i=1,j > call add2s2(x,z(1,i),c(i),ntot2) ! x = x + c z > ! i i > enddo > c if(iconv.eq.1) call dbg_write(x,nx2,ny2,nz2,nelv,'esol',3) > enddo > 9000 continue > c > divex = rnorm > c iter = iter - 1 > c > c DIAGNOSTICS > c call copy(w,x,ntot2) > c if (ifvcor) then > c xaver = glsc2(bm2,w,ntot2)/volvm2 > c call cadd(w,-xaver,ntot2) > c endif > c call copy(r,res,ntot2) !r = res > c call cdabdtp(r,w,h1,h2,h2inv,intype) ! r = A w > c do i=1,ntot2 > c r(i) = res(i) - r(i) ! r = res - r > c enddo > c call uzawa_gmres_temp(r,bm2inv,ntot2) > c ! ______ > c gamma(1) = sqrt(glsc2(r,r,ntot2)/volvm2) ! gamma = \/ (r,r) > c ! 1 > c print *, 'GMRES end resid:',gamma(1) > c END DIAGNOSTICS > call copy(res,x,ntot2) > c > if (ifvcor) then > xaver = glsc2(bm2,res,ntot2)/volvm2 > call cadd(res,-xaver,ntot2) > endif > c > etime1 = dnekclock()-etime1 > if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, > & etime1 > c call flush_hack > 9999 format(4X,I7,' U-Pres gmres: ',I6,1p5E13.4) > c > c > return > end > > c----------------------------------------------------------------------- > > subroutine uzawa_gmres_split0(l,u,b,binv,n) > integer n > real l(n),u(n),b(n),binv(n) > integer i > do i=1,n > l(i)=sqrt(binv(i)) > u(i)=sqrt(b(i)) > if(abs(u(i)*l(i)-1.0).gt.1e-13) print *, i, u(i)*l(i) > enddo > return > end > > c----------------------------------------------------------------------- > subroutine uzawa_gmres_split(l,u,b,binv,n) > integer n > real l(n),u(n),b(n),binv(n) > integer i > do i=1,n > c l(i)=sqrt(binv(i)) > c u(i)=sqrt(b(i)) > > c u(i)=sqrt(b(i)) > c l(i)=1./u(i) > > c l(i)=sqrt(binv(i)) > l(i)=1. > u(i)=1./l(i) > > > c if(abs(u(i)*l(i)-1.0).gt.1e-13)write(6,*) i,u(i)*l(i),' gmr_sp' > enddo > return > end > > c----------------------------------------------------------------------- > subroutine uzawa_gmres_temp(a,b,n) > integer n > real a(n),b(n) > integer i > do i=1,n > a(i)=sqrt(b(i))*a(i) > enddo > return > end > c----------------------------------------------------------------------- > subroutine ax(w,x,h1,h2,n) > include 'SIZE' > include 'TOTAL' > > c > c w = A*x for pressure iteration > c > > integer n > real w(n),x(n),h1(n),h2(n) > > imsh = 1 > isd = 1 > call axhelm (w,x,h1,h2,imsh,isd) > call dssum (w,nx1,ny1,nz1) > call col2 (w,pmask,n) > > return > end > c----------------------------------------------------------------------- > subroutine hmh_gmres(res,h1,h2,wt,iter) > > c Solve the Helmholtz equation by right-preconditioned c GMRES > iteration. > > > include 'SIZE' > include 'TOTAL' > include 'FDMH1' > include 'GMRES' > common /ctolpr/ divex > common /cprint/ ifprint > logical ifprint > real res (lx1*ly1*lz1*lelv) > real h1 (lx1,ly1,lz1,lelv) > real h2 (lx1,ly1,lz1,lelv) > real wt (lx1,ly1,lz1,lelv) > > common /scrcg/ d(lx1*ly1*lz1*lelv),wk(lx1*ly1*lz1*lelv) > > common /cgmres1/ y(lgmres) > common /ctmp0/ wk1(lgmres),wk2(lgmres) > real alpha, l, temp > integer j,m > > logical iflag > save iflag > data iflag /.false./ > real norm_fac > save norm_fac > > real*8 etime1,dnekclock > > > n = nx1*ny1*nz1*nelv > > etime1 = dnekclock() > etime_p = 0. > divex = 0. > iter = 0 > m = lgmres > > if(.not.iflag) then > iflag=.true. > call uzawa_gmres_split(ml,mu,bm1,binvm1,nx1*ny1*nz1*nelv) > norm_fac = 1./sqrt(volvm1) > endif > > call set_fdm_prec_h1b(d,h1,h2,nelv) > if (ifvcor) smean = -1./glsum(vmult,n) > > call chktcg1(tolps,res,h1,h2,pmask,vmult,1,1) > if (param(21).gt.0.and.tolps.gt.abs(param(21))) > $ tolps = abs(param(21)) > if (istep.eq.0) tolps = 1.e-4 > tolpss = tolps > c > iconv = 0 > call rzero(x,n) > > do while(iconv.eq.0.and.iter.lt.500) > > if(iter.eq.0) then ! -1 > call col3(r,ml,res,n) ! r = L res > c call copy(r,res,n) > else > !update residual > call copy (r,res,n) ! r = res > call ax (w,x,h1,h2,n) ! w = A x > call add2s2(r,w,-1.,n) ! r = r - w > ! -1 > call col2(r,ml,n) ! r = L r > endif > ! ______ > gamma(1) = sqrt(glsc3(r,r,wt,n)) ! gamma = \/ (r,r) > ! 1 > if(iter.eq.0) then > div0 = gamma(1)*norm_fac > if (param(21).lt.0) tolpss=abs(param(21))*div0 > endif > > !check for lucky convergence > rnorm = 0. > if(gamma(1) .eq. 0.) goto 9000 > temp = 1./gamma(1) > call cmult2(v(1,1),r,temp,n) ! v = r / gamma > ! 1 1 > do j=1,m > iter = iter+1 > ! -1 > call col3(w,mu,v(1,j),n) ! w = U v > ! j > > c . . . . . Overlapping Schwarz + coarse-grid . . . . . . . > > etime2 = dnekclock() > kfldfdm = ndim+1 > call fdm_h1 > $ (z(1,j),w,d,pmask,vmult,nelv,ktype(1,1,kfldfdm),wk) > call crs_solve_h1 (wk,w) c call > hsmg_solve(z(1,j),w) ! z = M w > ! j > call add2 (z(1,j),wk,n) > if (ifvcor) then > rmean = smean*glsc2(z(1,j),vmult,n) > call cadd(z(1,j),rmean,n) > endif > etime_p = etime_p + dnekclock()-etime2 > c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > > > call ax (w,z(1,j),h1,h2,n) ! w = A z > ! j > > ! -1 > call col2(w,ml,n) ! w = L w > > c !modified Gram-Schmidt > > c do i=1,j > c h(i,j)=glsc3(w,v(1,i),wt,n) ! h = (w,v ) > c ! i,j i > > c call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v > c enddo ! i,j i > > c 2-PASS GS, 1st pass: > > do i=1,j > h(i,j)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) > enddo ! i,j i > > call gop(h(1,j),wk1,'+ ',j) ! sum over P procs > > do i=1,j > call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v > enddo ! i,j i > > > c 2-PASS GS, 2nd pass: > c > c do i=1,j > c wk1(i)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) > c enddo ! i,j i > c ! > c call gop(wk1,wk2,'+ ',j) ! sum over P procs > c > c do i=1,j > c call add2s2(w,v(1,i),-wk1(i),n) ! w = w - h v > c h(i,j) = h(i,j) + wk1(i) ! i,j i > c enddo > > !apply Givens rotations to new column > do i=1,j-1 > temp = h(i,j) > h(i ,j)= c(i)*temp + s(i)*h(i+1,j) > h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) > enddo > ! ______ > alpha = sqrt(glsc3(w,w,wt,n)) ! alpha = \/ (w,w) > rnorm = 0. > if(alpha.eq.0.) goto 900 !converged > l = sqrt(h(j,j)*h(j,j)+alpha*alpha) > temp = 1./l > c(j) = h(j,j) * temp > s(j) = alpha * temp > h(j,j) = l > gamma(j+1) = -s(j) * gamma(j) > gamma(j) = c(j) * gamma(j) > > rnorm = abs(gamma(j+1))*norm_fac > ratio = rnorm/div0 > if (ifprint.and.nid.eq.0) > $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep > 66 format(i5,1p4e12.5,i8,' Divergence') > > #ifndef TST_WSCAL > if (rnorm .lt. tolpss) goto 900 !converged > #else > if (iter.gt.param(151)-1) goto 900 > #endif > if (j.eq.m) goto 1000 !not converged, restart > > temp = 1./alpha > call cmult2(v(1,j+1),w,temp,n) ! v = w / alpha > ! j+1 > enddo > 900 iconv = 1 > 1000 continue > !back substitution > ! -1 > !c = H gamma > do k=j,1,-1 > temp = gamma(k) > do i=j,k+1,-1 > temp = temp - h(k,i)*c(i) > enddo > c(k) = temp/h(k,k) > enddo > !sum up Arnoldi vectors > do i=1,j > call add2s2(x,z(1,i),c(i),n) ! x = x + c z > enddo ! i i > c if(iconv.eq.1) call dbg_write(x,nx1,ny1,nz1,nelv,'esol',3) > enddo > 9000 continue > c > divex = rnorm > call copy(res,x,n) > c > if (ifvcor) then > xaver = glsc2(bm1,res,n)/volvm1 > call cadd(res,-xaver,n) > endif > c > etime1 = dnekclock()-etime1 > if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, > & etime1 > c call flush_hack > 9999 format(4X,I7,' PRES gmres: ',I6,1p5E13.4) > > return > end > c----------------------------------------------------------------------- > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sun Apr 25 12:49:53 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 25 Apr 2010 12:49:53 -0500 (CDT) Subject: [Nek5000-users] Residuals for post-processing In-Reply-To: <4BD45A25.4040005@vt.edu> References: <4BCEF889.1050105@vt.edu> <4BD45A25.4040005@vt.edu> Message-ID: Hi Markus, The issue here is that "res" is an argument passed into the gmres solver and is not the stored value that is held in GMRES, so a seg fault would be a natural failure. The stored values are x,r,v,and z. Paul On Sun, 25 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > this is what I added to usrchk: > --- > include 'GMRES' > if (istep.gt.0) then > call outpost(vx,vy,vz,res,t,'res') > call exitti('quit in gmres$',n) > endif > --- > Unfortunately, this causes the code to crash whenever outpost is called: > --- > 120 1.00000E-06 8.11690E-04 5.58247E-01 1.45400E-03 1 Divergence > 1 U-Pres gmres: 120 8.1169E-04 1.0000E-06 5.5825E-01 > 2.8286E+00 8.0148E+00 > 1 DNORM, DIVEX 0.35002708528548815 8.11690205515358640E-004 > 1 5.0000E-03 8.3137E+00 Fluid done > filt amp 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0125 0.0500 > filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.9875 0.9500 > ./nek: line 7: 11765 Segmentation fault (core dumped) ./nek5000 > > real 0m27.297s > user 0m9.348s > sys 0m1.124s > --- > > I tried with pr instead of res, that works. Is it possible that res is not an > array but a single number? > Where are the residuals for velocity and passive scalars stored? > > I added the divergence procedure to the outflow, there is no back flow. The > problem is not that the simulation blows up (at least for the time steps I am > doing), it is that the pressure residuals don't fall below the specified > limit when I increase lx1. This is for both PN/PN-2 and PN/PN and not a > function of dt. > > Thanks, > Markus > > > > nek5000-users at lists.mcs.anl.gov wrote: >> >> Hi Markus, >> >> pressure residuals are in gmres >> >> You could output them via: >> >> call outpost(x,y,z,res,t,'res') >> >> where x,y,z,t are arrays of your choice and res >> is the array you want to look at. >> >> Nek will convert the res mesh to the velocity mesh >> if needed. I usually follow such a call with >> >> call exitti('quit in gmres$',n) >> >> because prepost() uses some scratch common blocks >> that are potentially shared with the calling routine >> (not in the case of gmres, I think...) -- so data might be corrupted after >> such a call. The idea of >> prepost was to be called in between timesteps, when >> such memory re-use would be admissable. The alternative >> would be to define your own storage in a common block, >> save the residuals to this locale, then loop through >> calls to outpost in userchk afterwards... I've done >> that in the past. >> >> All this being said, I'm not 100% certain that the >> iterative solvers is the place to look for the difficulty. >> Most problems arise from spatial resolution issues...or >> temporal stability problems. The latter can be identified >> by drastic reduction in dt. >> >> What exactly is blowing up for you? >> >> Paul >> >> >> On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> I'd like to save the residuals for the pressure iterations (PN/PN-2 as >>> well as PN/PN) into a scalar variable (scalar 0, instead of temperature >>> say) for each grid point in order to see where my solution diverges. >>> Is there a way to add something to the .usr file to do that? I couldn't >>> find the variable in the code and also wouldn't know how to save something >>> from the lx2=lx1-2 grid onto the lx1 grid. >>> Would this also be possible with the velocity residuals? >>> >>> Thanks, >>> Markus >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> uuuu >> c----------------------------------------------------------------------- >> subroutine uzawa_gmres(res,h1,h2,h2inv,intype,iter) >> >> c Solve the pressure equation by right-preconditioned c GMRES >> iteration. >> c intype = 0 (steady) >> c intype = 1 (explicit) >> c intype = -1 (implicit) >> >> include 'SIZE' >> include 'TOTAL' >> include 'GMRES' >> common /ctolpr/ divex >> common /cprint/ ifprint >> logical ifprint >> real res (lx2*ly2*lz2*lelv) >> real h1 (lx1,ly1,lz1,lelv) >> real h2 (lx1,ly1,lz1,lelv) >> real h2inv(lx1,ly1,lz1,lelv) >> >> common /scrmg/ wp (lx2,ly2,lz2,lelv) >> >> common /ctmp0/ wk1(lgmres),wk2(lgmres) >> common /cgmres1/ y(lgmres) >> >> real alpha, l, temp >> integer j,m >> c >> logical iflag >> save iflag >> data iflag /.false./ >> real norm_fac >> save norm_fac >> c >> real*8 etime1,dnekclock >> c >> if(.not.iflag) then >> iflag=.true. >> call uzawa_gmres_split0(ml,mu,bm2,bm2inv,nx2*ny2*nz2*nelv) >> norm_fac = 1./sqrt(volvm2) >> endif >> c >> etime1 = dnekclock() >> etime_p = 0. >> divex = 0. >> iter = 0 >> m = lgmres >> c >> call chktcg2(tolps,res,iconv) >> if (param(21).gt.0.and.tolps.gt.abs(param(21))) >> $ tolps = abs(param(21)) >> c if (param(21).lt.0) tolps = abs(param(21)) >> if (istep.eq.0) tolps = 1.e-4 >> tolpss = tolps >> c >> ntot2 = nx2*ny2*nz2*nelv >> c >> iconv = 0 >> call rzero(x,ntot2) >> >> do while(iconv.eq.0.and.iter.lt.100) >> >> if(iter.eq.0) then >> ! -1 >> call col3(r,ml,res,ntot2) ! r = L res >> c call copy(r,res,ntot2) >> else >> !update residual >> call copy(r,res,ntot2) ! r = res >> call cdabdtp(w,x,h1,h2,h2inv,intype) ! w = A x >> call add2s2(r,w,-1.,ntot2) ! r = r - w >> ! -1 >> call col2(r,ml,ntot2) ! r = L r >> endif >> ! ______ >> gamma(1) = sqrt(glsc2(r,r,ntot2)) ! gamma = \/ (r,r) >> ! 1 >> if(iter.eq.0) then >> div0 = gamma(1)*norm_fac >> if (param(21).lt.0) tolpss=abs(param(21))*div0 >> endif >> >> !check for lucky convergence >> rnorm = 0. >> if(gamma(1) .eq. 0.) goto 9000 >> temp = 1./gamma(1) >> call cmult2(v(1,1),r,temp,ntot2) ! v = r / gamma >> ! 1 1 >> do j=1,m >> iter = iter+1 >> ! -1 >> call col3(w,mu,v(1,j),ntot2) ! w = U v >> ! j >> >> etime2 = dnekclock() >> if(param(43).eq.1) then >> call uzprec(z(1,j),w,h1,h2,intype,wp) >> else ! -1 >> call hsmg_solve(z(1,j),w) ! z = M w >> endif >> etime_p = etime_p + dnekclock()-etime2 >> >> call cdabdtp(w,z(1,j), ! w = A z >> $ h1,h2,h2inv,intype) ! j >> >> ! -1 >> call col2(w,ml,ntot2) ! w = L w >> >> c !modified Gram-Schmidt >> c do i=1,j >> c h(i,j)=glsc2(w,v(1,i),ntot2) ! h = (w,v ) >> c ! i,j i >> c call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v >> c enddo ! i,j i >> >> >> c 2-PASS GS, 1st pass: >> >> do i=1,j >> h(i,j)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) >> enddo ! i,j i >> >> call gop(h(1,j),wk1,'+ ',j) ! sum over P procs >> >> do i=1,j >> call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v >> enddo ! i,j i >> >> >> c 2-PASS GS, 2nd pass: >> c >> c do i=1,j >> c wk1(i)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) >> c enddo ! i,j i >> c ! >> c call gop(wk1,wk2,'+ ',j) ! sum over P procs >> c >> c do i=1,j >> c call add2s2(w,v(1,i),-wk1(i),ntot2)! w = w - h v >> c h(i,j) = h(i,j) + wk1(i) ! i,j i >> c enddo >> >> >> !apply Givens rotations to new column >> do i=1,j-1 >> temp = h(i,j) >> h(i ,j)= c(i)*temp + s(i)*h(i+1,j) >> h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) >> enddo >> ! ______ >> alpha = sqrt(glsc2(w,w,ntot2)) ! alpha = \/ (w,w) >> rnorm = 0. >> if(alpha.eq.0.) goto 900 !converged >> l = sqrt(h(j,j)*h(j,j)+alpha*alpha) >> temp = 1./l >> c(j) = h(j,j) * temp >> s(j) = alpha * temp >> h(j,j) = l >> gamma(j+1) = -s(j) * gamma(j) >> gamma(j) = c(j) * gamma(j) >> >> c call outmat(h,m,j,' h ',j) >> >> rnorm = abs(gamma(j+1))*norm_fac >> ratio = rnorm/div0 >> if (ifprint.and.nid.eq.0) >> $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep >> 66 format(i5,1p4e12.5,i8,' Divergence') >> >> #ifndef TST_WSCAL >> if (rnorm .lt. tolpss) goto 900 !converged >> #else >> if (iter.gt.param(151)-1) goto 900 >> #endif >> if (j.eq.m) goto 1000 !not converged, restart >> >> temp = 1./alpha >> call cmult2(v(1,j+1),w,temp,ntot2) ! v = w / alpha >> ! j+1 >> enddo >> 900 iconv = 1 >> 1000 continue >> !back substitution >> ! -1 >> !c = H gamma >> do k=j,1,-1 >> temp = gamma(k) >> do i=j,k+1,-1 >> temp = temp - h(k,i)*c(i) >> enddo >> c(k) = temp/h(k,k) >> enddo >> !sum up Arnoldi vectors >> do i=1,j >> call add2s2(x,z(1,i),c(i),ntot2) ! x = x + c z >> ! i i >> enddo >> c if(iconv.eq.1) call dbg_write(x,nx2,ny2,nz2,nelv,'esol',3) >> enddo >> 9000 continue >> c >> divex = rnorm >> c iter = iter - 1 >> c >> c DIAGNOSTICS >> c call copy(w,x,ntot2) >> c if (ifvcor) then >> c xaver = glsc2(bm2,w,ntot2)/volvm2 >> c call cadd(w,-xaver,ntot2) >> c endif >> c call copy(r,res,ntot2) !r = res >> c call cdabdtp(r,w,h1,h2,h2inv,intype) ! r = A w >> c do i=1,ntot2 >> c r(i) = res(i) - r(i) ! r = res - r >> c enddo >> c call uzawa_gmres_temp(r,bm2inv,ntot2) >> c ! ______ >> c gamma(1) = sqrt(glsc2(r,r,ntot2)/volvm2) ! gamma = \/ (r,r) c >> ! 1 >> c print *, 'GMRES end resid:',gamma(1) >> c END DIAGNOSTICS >> call copy(res,x,ntot2) >> c >> if (ifvcor) then >> xaver = glsc2(bm2,res,ntot2)/volvm2 >> call cadd(res,-xaver,ntot2) >> endif >> c >> etime1 = dnekclock()-etime1 >> if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, >> & etime1 >> c call flush_hack >> 9999 format(4X,I7,' U-Pres gmres: ',I6,1p5E13.4) >> c >> c >> return >> end >> >> c----------------------------------------------------------------------- >> >> subroutine uzawa_gmres_split0(l,u,b,binv,n) >> integer n >> real l(n),u(n),b(n),binv(n) >> integer i >> do i=1,n >> l(i)=sqrt(binv(i)) >> u(i)=sqrt(b(i)) >> if(abs(u(i)*l(i)-1.0).gt.1e-13) print *, i, u(i)*l(i) >> enddo >> return >> end >> >> c----------------------------------------------------------------------- >> subroutine uzawa_gmres_split(l,u,b,binv,n) >> integer n >> real l(n),u(n),b(n),binv(n) >> integer i >> do i=1,n >> c l(i)=sqrt(binv(i)) >> c u(i)=sqrt(b(i)) >> >> c u(i)=sqrt(b(i)) >> c l(i)=1./u(i) >> >> c l(i)=sqrt(binv(i)) >> l(i)=1. >> u(i)=1./l(i) >> >> >> c if(abs(u(i)*l(i)-1.0).gt.1e-13)write(6,*) i,u(i)*l(i),' gmr_sp' >> enddo >> return >> end >> >> c----------------------------------------------------------------------- >> subroutine uzawa_gmres_temp(a,b,n) >> integer n >> real a(n),b(n) >> integer i >> do i=1,n >> a(i)=sqrt(b(i))*a(i) >> enddo >> return >> end >> c----------------------------------------------------------------------- >> subroutine ax(w,x,h1,h2,n) >> include 'SIZE' >> include 'TOTAL' >> >> c >> c w = A*x for pressure iteration >> c >> >> integer n >> real w(n),x(n),h1(n),h2(n) >> >> imsh = 1 >> isd = 1 >> call axhelm (w,x,h1,h2,imsh,isd) >> call dssum (w,nx1,ny1,nz1) >> call col2 (w,pmask,n) >> >> return >> end >> c----------------------------------------------------------------------- >> subroutine hmh_gmres(res,h1,h2,wt,iter) >> >> c Solve the Helmholtz equation by right-preconditioned c GMRES >> iteration. >> >> >> include 'SIZE' >> include 'TOTAL' >> include 'FDMH1' >> include 'GMRES' >> common /ctolpr/ divex >> common /cprint/ ifprint >> logical ifprint >> real res (lx1*ly1*lz1*lelv) >> real h1 (lx1,ly1,lz1,lelv) >> real h2 (lx1,ly1,lz1,lelv) >> real wt (lx1,ly1,lz1,lelv) >> >> common /scrcg/ d(lx1*ly1*lz1*lelv),wk(lx1*ly1*lz1*lelv) >> >> common /cgmres1/ y(lgmres) >> common /ctmp0/ wk1(lgmres),wk2(lgmres) >> real alpha, l, temp >> integer j,m >> >> logical iflag >> save iflag >> data iflag /.false./ >> real norm_fac >> save norm_fac >> >> real*8 etime1,dnekclock >> >> >> n = nx1*ny1*nz1*nelv >> >> etime1 = dnekclock() >> etime_p = 0. >> divex = 0. >> iter = 0 >> m = lgmres >> >> if(.not.iflag) then >> iflag=.true. >> call uzawa_gmres_split(ml,mu,bm1,binvm1,nx1*ny1*nz1*nelv) >> norm_fac = 1./sqrt(volvm1) >> endif >> >> call set_fdm_prec_h1b(d,h1,h2,nelv) >> if (ifvcor) smean = -1./glsum(vmult,n) >> >> call chktcg1(tolps,res,h1,h2,pmask,vmult,1,1) >> if (param(21).gt.0.and.tolps.gt.abs(param(21))) >> $ tolps = abs(param(21)) >> if (istep.eq.0) tolps = 1.e-4 >> tolpss = tolps >> c >> iconv = 0 >> call rzero(x,n) >> >> do while(iconv.eq.0.and.iter.lt.500) >> >> if(iter.eq.0) then ! -1 >> call col3(r,ml,res,n) ! r = L res >> c call copy(r,res,n) >> else >> !update residual >> call copy (r,res,n) ! r = res >> call ax (w,x,h1,h2,n) ! w = A x >> call add2s2(r,w,-1.,n) ! r = r - w >> ! -1 >> call col2(r,ml,n) ! r = L r >> endif >> ! ______ >> gamma(1) = sqrt(glsc3(r,r,wt,n)) ! gamma = \/ (r,r) >> ! 1 >> if(iter.eq.0) then >> div0 = gamma(1)*norm_fac >> if (param(21).lt.0) tolpss=abs(param(21))*div0 >> endif >> >> !check for lucky convergence >> rnorm = 0. >> if(gamma(1) .eq. 0.) goto 9000 >> temp = 1./gamma(1) >> call cmult2(v(1,1),r,temp,n) ! v = r / gamma >> ! 1 1 >> do j=1,m >> iter = iter+1 >> ! -1 >> call col3(w,mu,v(1,j),n) ! w = U v >> ! j >> >> c . . . . . Overlapping Schwarz + coarse-grid . . . . . . . >> >> etime2 = dnekclock() >> kfldfdm = ndim+1 >> call fdm_h1 >> $ (z(1,j),w,d,pmask,vmult,nelv,ktype(1,1,kfldfdm),wk) >> call crs_solve_h1 (wk,w) c call hsmg_solve(z(1,j),w) >> ! z = M w >> ! j >> call add2 (z(1,j),wk,n) >> if (ifvcor) then >> rmean = smean*glsc2(z(1,j),vmult,n) >> call cadd(z(1,j),rmean,n) >> endif >> etime_p = etime_p + dnekclock()-etime2 >> c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> >> >> call ax (w,z(1,j),h1,h2,n) ! w = A z >> ! j >> >> ! -1 >> call col2(w,ml,n) ! w = L w >> >> c !modified Gram-Schmidt >> >> c do i=1,j >> c h(i,j)=glsc3(w,v(1,i),wt,n) ! h = (w,v ) >> c ! i,j i >> >> c call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v >> c enddo ! i,j i >> >> c 2-PASS GS, 1st pass: >> >> do i=1,j >> h(i,j)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) >> enddo ! i,j i >> >> call gop(h(1,j),wk1,'+ ',j) ! sum over P procs >> >> do i=1,j >> call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v >> enddo ! i,j i >> >> >> c 2-PASS GS, 2nd pass: >> c >> c do i=1,j >> c wk1(i)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) >> c enddo ! i,j i >> c ! >> c call gop(wk1,wk2,'+ ',j) ! sum over P procs >> c >> c do i=1,j >> c call add2s2(w,v(1,i),-wk1(i),n) ! w = w - h v >> c h(i,j) = h(i,j) + wk1(i) ! i,j i >> c enddo >> >> !apply Givens rotations to new column >> do i=1,j-1 >> temp = h(i,j) >> h(i ,j)= c(i)*temp + s(i)*h(i+1,j) >> h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) >> enddo >> ! ______ >> alpha = sqrt(glsc3(w,w,wt,n)) ! alpha = \/ (w,w) >> rnorm = 0. >> if(alpha.eq.0.) goto 900 !converged >> l = sqrt(h(j,j)*h(j,j)+alpha*alpha) >> temp = 1./l >> c(j) = h(j,j) * temp >> s(j) = alpha * temp >> h(j,j) = l >> gamma(j+1) = -s(j) * gamma(j) >> gamma(j) = c(j) * gamma(j) >> >> rnorm = abs(gamma(j+1))*norm_fac >> ratio = rnorm/div0 >> if (ifprint.and.nid.eq.0) >> $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep >> 66 format(i5,1p4e12.5,i8,' Divergence') >> >> #ifndef TST_WSCAL >> if (rnorm .lt. tolpss) goto 900 !converged >> #else >> if (iter.gt.param(151)-1) goto 900 >> #endif >> if (j.eq.m) goto 1000 !not converged, restart >> >> temp = 1./alpha >> call cmult2(v(1,j+1),w,temp,n) ! v = w / alpha >> ! j+1 >> enddo >> 900 iconv = 1 >> 1000 continue >> !back substitution >> ! -1 >> !c = H gamma >> do k=j,1,-1 >> temp = gamma(k) >> do i=j,k+1,-1 >> temp = temp - h(k,i)*c(i) >> enddo >> c(k) = temp/h(k,k) >> enddo >> !sum up Arnoldi vectors >> do i=1,j >> call add2s2(x,z(1,i),c(i),n) ! x = x + c z >> enddo ! i i >> c if(iconv.eq.1) call dbg_write(x,nx1,ny1,nz1,nelv,'esol',3) >> enddo >> 9000 continue >> c >> divex = rnorm >> call copy(res,x,n) >> c >> if (ifvcor) then >> xaver = glsc2(bm1,res,n)/volvm1 >> call cadd(res,-xaver,n) >> endif >> c >> etime1 = dnekclock()-etime1 >> if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, >> & etime1 >> c call flush_hack >> 9999 format(4X,I7,' PRES gmres: ',I6,1p5E13.4) >> >> return >> end >> c----------------------------------------------------------------------- >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sun Apr 25 12:28:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 25 Apr 2010 13:28:49 -0400 Subject: [Nek5000-users] Residuals for post-processing In-Reply-To: References: <4BCEF889.1050105@vt.edu> <4BD45A25.4040005@vt.edu> Message-ID: <4BD47BD1.6020804@vt.edu> Hi, uh-oh, I think I misread your first response - your suggestion was to include: call outpost(x,y,z,res,t,'res') call exitti('quit in gmres$',n) in gmres.f, not in usrchk ? What do x,v,and z stand for? Thanks, Markus nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Markus, > > The issue here is that "res" is an argument passed into > the gmres solver and is not the stored value that is held > in GMRES, so a seg fault would be a natural failure. > > The stored values are x,r,v,and z. > > Paul > > > On Sun, 25 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> this is what I added to usrchk: >> --- >> include 'GMRES' >> if (istep.gt.0) then >> call outpost(vx,vy,vz,res,t,'res') >> call exitti('quit in gmres$',n) >> endif >> --- >> Unfortunately, this causes the code to crash whenever outpost is called: >> --- >> 120 1.00000E-06 8.11690E-04 5.58247E-01 1.45400E-03 1 Divergence >> 1 U-Pres gmres: 120 8.1169E-04 1.0000E-06 >> 5.5825E-01 2.8286E+00 8.0148E+00 >> 1 DNORM, DIVEX 0.35002708528548815 8.11690205515358640E-004 >> 1 5.0000E-03 8.3137E+00 Fluid done >> filt amp 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0125 0.0500 >> filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.9875 0.9500 >> ./nek: line 7: 11765 Segmentation fault (core dumped) ./nek5000 >> >> real 0m27.297s >> user 0m9.348s >> sys 0m1.124s >> --- >> >> I tried with pr instead of res, that works. Is it possible that res is >> not an array but a single number? >> Where are the residuals for velocity and passive scalars stored? >> >> I added the divergence procedure to the outflow, there is no back >> flow. The problem is not that the simulation blows up (at least for >> the time steps I am doing), it is that the pressure residuals don't >> fall below the specified limit when I increase lx1. This is for both >> PN/PN-2 and PN/PN and not a function of dt. >> >> Thanks, >> Markus >> >> >> >> nek5000-users at lists.mcs.anl.gov wrote: >>> >>> Hi Markus, >>> >>> pressure residuals are in gmres >>> >>> You could output them via: >>> >>> call outpost(x,y,z,res,t,'res') >>> >>> where x,y,z,t are arrays of your choice and res >>> is the array you want to look at. >>> >>> Nek will convert the res mesh to the velocity mesh >>> if needed. I usually follow such a call with >>> >>> call exitti('quit in gmres$',n) >>> >>> because prepost() uses some scratch common blocks >>> that are potentially shared with the calling routine >>> (not in the case of gmres, I think...) -- so data might be corrupted >>> after such a call. The idea of >>> prepost was to be called in between timesteps, when >>> such memory re-use would be admissable. The alternative >>> would be to define your own storage in a common block, >>> save the residuals to this locale, then loop through >>> calls to outpost in userchk afterwards... I've done >>> that in the past. >>> >>> All this being said, I'm not 100% certain that the >>> iterative solvers is the place to look for the difficulty. >>> Most problems arise from spatial resolution issues...or >>> temporal stability problems. The latter can be identified >>> by drastic reduction in dt. >>> >>> What exactly is blowing up for you? >>> >>> Paul >>> >>> >>> On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi, >>>> >>>> I'd like to save the residuals for the pressure iterations (PN/PN-2 >>>> as well as PN/PN) into a scalar variable (scalar 0, instead of >>>> temperature say) for each grid point in order to see where my >>>> solution diverges. >>>> Is there a way to add something to the .usr file to do that? I >>>> couldn't find the variable in the code and also wouldn't know how to >>>> save something from the lx2=lx1-2 grid onto the lx1 grid. >>>> Would this also be possible with the velocity residuals? >>>> >>>> Thanks, >>>> Markus >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> uuuu >>> c----------------------------------------------------------------------- >>> subroutine uzawa_gmres(res,h1,h2,h2inv,intype,iter) >>> >>> c Solve the pressure equation by right-preconditioned c GMRES >>> iteration. >>> c intype = 0 (steady) >>> c intype = 1 (explicit) >>> c intype = -1 (implicit) >>> >>> include 'SIZE' >>> include 'TOTAL' >>> include 'GMRES' >>> common /ctolpr/ divex >>> common /cprint/ ifprint >>> logical ifprint >>> real res (lx2*ly2*lz2*lelv) >>> real h1 (lx1,ly1,lz1,lelv) >>> real h2 (lx1,ly1,lz1,lelv) >>> real h2inv(lx1,ly1,lz1,lelv) >>> >>> common /scrmg/ wp (lx2,ly2,lz2,lelv) >>> >>> common /ctmp0/ wk1(lgmres),wk2(lgmres) >>> common /cgmres1/ y(lgmres) >>> >>> real alpha, l, temp >>> integer j,m >>> c >>> logical iflag >>> save iflag >>> data iflag /.false./ >>> real norm_fac >>> save norm_fac >>> c >>> real*8 etime1,dnekclock >>> c >>> if(.not.iflag) then >>> iflag=.true. >>> call uzawa_gmres_split0(ml,mu,bm2,bm2inv,nx2*ny2*nz2*nelv) >>> norm_fac = 1./sqrt(volvm2) >>> endif >>> c >>> etime1 = dnekclock() >>> etime_p = 0. >>> divex = 0. >>> iter = 0 >>> m = lgmres >>> c >>> call chktcg2(tolps,res,iconv) >>> if (param(21).gt.0.and.tolps.gt.abs(param(21))) >>> $ tolps = abs(param(21)) >>> c if (param(21).lt.0) tolps = abs(param(21)) >>> if (istep.eq.0) tolps = 1.e-4 >>> tolpss = tolps >>> c >>> ntot2 = nx2*ny2*nz2*nelv >>> c >>> iconv = 0 >>> call rzero(x,ntot2) >>> >>> do while(iconv.eq.0.and.iter.lt.100) >>> >>> if(iter.eq.0) then >>> ! -1 >>> call col3(r,ml,res,ntot2) ! r = L res >>> c call copy(r,res,ntot2) >>> else >>> !update residual >>> call copy(r,res,ntot2) ! r = res >>> call cdabdtp(w,x,h1,h2,h2inv,intype) ! w = A x >>> call add2s2(r,w,-1.,ntot2) ! r = r - w >>> ! -1 >>> call col2(r,ml,ntot2) ! r = L r >>> endif >>> ! ______ >>> gamma(1) = sqrt(glsc2(r,r,ntot2)) ! gamma = \/ (r,r) >>> ! 1 >>> if(iter.eq.0) then >>> div0 = gamma(1)*norm_fac >>> if (param(21).lt.0) tolpss=abs(param(21))*div0 >>> endif >>> >>> !check for lucky convergence >>> rnorm = 0. >>> if(gamma(1) .eq. 0.) goto 9000 >>> temp = 1./gamma(1) >>> call cmult2(v(1,1),r,temp,ntot2) ! v = r / gamma >>> ! 1 1 >>> do j=1,m >>> iter = iter+1 >>> ! -1 >>> call col3(w,mu,v(1,j),ntot2) ! w = U v >>> ! j >>> >>> etime2 = dnekclock() >>> if(param(43).eq.1) then >>> call uzprec(z(1,j),w,h1,h2,intype,wp) >>> else ! -1 >>> call hsmg_solve(z(1,j),w) ! z = M w >>> endif >>> etime_p = etime_p + dnekclock()-etime2 >>> >>> call cdabdtp(w,z(1,j), ! w = A z >>> $ h1,h2,h2inv,intype) ! j >>> >>> ! -1 >>> call col2(w,ml,ntot2) ! w = L w >>> >>> c !modified Gram-Schmidt >>> c do i=1,j >>> c h(i,j)=glsc2(w,v(1,i),ntot2) ! h = (w,v ) >>> c ! i,j i >>> c call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v >>> c enddo ! i,j i >>> >>> >>> c 2-PASS GS, 1st pass: >>> >>> do i=1,j >>> h(i,j)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) >>> enddo ! i,j i >>> >>> call gop(h(1,j),wk1,'+ ',j) ! sum over P procs >>> >>> do i=1,j >>> call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v >>> enddo ! i,j i >>> >>> >>> c 2-PASS GS, 2nd pass: >>> c >>> c do i=1,j >>> c wk1(i)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) >>> c enddo ! i,j i >>> c ! >>> c call gop(wk1,wk2,'+ ',j) ! sum over P procs >>> c >>> c do i=1,j >>> c call add2s2(w,v(1,i),-wk1(i),ntot2)! w = w - h v >>> c h(i,j) = h(i,j) + wk1(i) ! i,j i >>> c enddo >>> >>> >>> !apply Givens rotations to new column >>> do i=1,j-1 >>> temp = h(i,j) >>> h(i ,j)= c(i)*temp + s(i)*h(i+1,j) >>> h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) >>> enddo >>> ! ______ >>> alpha = sqrt(glsc2(w,w,ntot2)) ! alpha = \/ (w,w) >>> rnorm = 0. >>> if(alpha.eq.0.) goto 900 !converged >>> l = sqrt(h(j,j)*h(j,j)+alpha*alpha) >>> temp = 1./l >>> c(j) = h(j,j) * temp >>> s(j) = alpha * temp >>> h(j,j) = l >>> gamma(j+1) = -s(j) * gamma(j) >>> gamma(j) = c(j) * gamma(j) >>> >>> c call outmat(h,m,j,' h ',j) >>> >>> rnorm = abs(gamma(j+1))*norm_fac >>> ratio = rnorm/div0 >>> if (ifprint.and.nid.eq.0) >>> $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep >>> 66 format(i5,1p4e12.5,i8,' Divergence') >>> >>> #ifndef TST_WSCAL >>> if (rnorm .lt. tolpss) goto 900 !converged >>> #else >>> if (iter.gt.param(151)-1) goto 900 >>> #endif >>> if (j.eq.m) goto 1000 !not converged, restart >>> >>> temp = 1./alpha >>> call cmult2(v(1,j+1),w,temp,ntot2) ! v = w / alpha >>> ! j+1 >>> enddo >>> 900 iconv = 1 >>> 1000 continue >>> !back substitution >>> ! -1 >>> !c = H gamma >>> do k=j,1,-1 >>> temp = gamma(k) >>> do i=j,k+1,-1 >>> temp = temp - h(k,i)*c(i) >>> enddo >>> c(k) = temp/h(k,k) >>> enddo >>> !sum up Arnoldi vectors >>> do i=1,j >>> call add2s2(x,z(1,i),c(i),ntot2) ! x = x + c z >>> ! i i >>> enddo >>> c if(iconv.eq.1) call dbg_write(x,nx2,ny2,nz2,nelv,'esol',3) >>> enddo >>> 9000 continue >>> c >>> divex = rnorm >>> c iter = iter - 1 >>> c >>> c DIAGNOSTICS >>> c call copy(w,x,ntot2) >>> c if (ifvcor) then >>> c xaver = glsc2(bm2,w,ntot2)/volvm2 >>> c call cadd(w,-xaver,ntot2) >>> c endif >>> c call copy(r,res,ntot2) !r = res >>> c call cdabdtp(r,w,h1,h2,h2inv,intype) ! r = A w >>> c do i=1,ntot2 >>> c r(i) = res(i) - r(i) ! r = res - r >>> c enddo >>> c call uzawa_gmres_temp(r,bm2inv,ntot2) >>> c ! ______ >>> c gamma(1) = sqrt(glsc2(r,r,ntot2)/volvm2) ! gamma = \/ (r,r) c >>> ! 1 >>> c print *, 'GMRES end resid:',gamma(1) >>> c END DIAGNOSTICS >>> call copy(res,x,ntot2) >>> c >>> if (ifvcor) then >>> xaver = glsc2(bm2,res,ntot2)/volvm2 >>> call cadd(res,-xaver,ntot2) >>> endif >>> c >>> etime1 = dnekclock()-etime1 >>> if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, >>> & etime1 >>> c call flush_hack >>> 9999 format(4X,I7,' U-Pres gmres: ',I6,1p5E13.4) >>> c >>> c >>> return >>> end >>> >>> c----------------------------------------------------------------------- >>> >>> subroutine uzawa_gmres_split0(l,u,b,binv,n) >>> integer n >>> real l(n),u(n),b(n),binv(n) >>> integer i >>> do i=1,n >>> l(i)=sqrt(binv(i)) >>> u(i)=sqrt(b(i)) >>> if(abs(u(i)*l(i)-1.0).gt.1e-13) print *, i, u(i)*l(i) >>> enddo >>> return >>> end >>> >>> c----------------------------------------------------------------------- >>> subroutine uzawa_gmres_split(l,u,b,binv,n) >>> integer n >>> real l(n),u(n),b(n),binv(n) >>> integer i >>> do i=1,n >>> c l(i)=sqrt(binv(i)) >>> c u(i)=sqrt(b(i)) >>> >>> c u(i)=sqrt(b(i)) >>> c l(i)=1./u(i) >>> >>> c l(i)=sqrt(binv(i)) >>> l(i)=1. >>> u(i)=1./l(i) >>> >>> >>> c if(abs(u(i)*l(i)-1.0).gt.1e-13)write(6,*) i,u(i)*l(i),' gmr_sp' >>> enddo >>> return >>> end >>> >>> c----------------------------------------------------------------------- >>> subroutine uzawa_gmres_temp(a,b,n) >>> integer n >>> real a(n),b(n) >>> integer i >>> do i=1,n >>> a(i)=sqrt(b(i))*a(i) >>> enddo >>> return >>> end >>> c----------------------------------------------------------------------- >>> subroutine ax(w,x,h1,h2,n) >>> include 'SIZE' >>> include 'TOTAL' >>> >>> c >>> c w = A*x for pressure iteration >>> c >>> >>> integer n >>> real w(n),x(n),h1(n),h2(n) >>> >>> imsh = 1 >>> isd = 1 >>> call axhelm (w,x,h1,h2,imsh,isd) >>> call dssum (w,nx1,ny1,nz1) >>> call col2 (w,pmask,n) >>> >>> return >>> end >>> c----------------------------------------------------------------------- >>> subroutine hmh_gmres(res,h1,h2,wt,iter) >>> >>> c Solve the Helmholtz equation by right-preconditioned c >>> GMRES iteration. >>> >>> >>> include 'SIZE' >>> include 'TOTAL' >>> include 'FDMH1' >>> include 'GMRES' >>> common /ctolpr/ divex >>> common /cprint/ ifprint >>> logical ifprint >>> real res (lx1*ly1*lz1*lelv) >>> real h1 (lx1,ly1,lz1,lelv) >>> real h2 (lx1,ly1,lz1,lelv) >>> real wt (lx1,ly1,lz1,lelv) >>> >>> common /scrcg/ d(lx1*ly1*lz1*lelv),wk(lx1*ly1*lz1*lelv) >>> >>> common /cgmres1/ y(lgmres) >>> common /ctmp0/ wk1(lgmres),wk2(lgmres) >>> real alpha, l, temp >>> integer j,m >>> >>> logical iflag >>> save iflag >>> data iflag /.false./ >>> real norm_fac >>> save norm_fac >>> >>> real*8 etime1,dnekclock >>> >>> >>> n = nx1*ny1*nz1*nelv >>> >>> etime1 = dnekclock() >>> etime_p = 0. >>> divex = 0. >>> iter = 0 >>> m = lgmres >>> >>> if(.not.iflag) then >>> iflag=.true. >>> call uzawa_gmres_split(ml,mu,bm1,binvm1,nx1*ny1*nz1*nelv) >>> norm_fac = 1./sqrt(volvm1) >>> endif >>> >>> call set_fdm_prec_h1b(d,h1,h2,nelv) >>> if (ifvcor) smean = -1./glsum(vmult,n) >>> >>> call chktcg1(tolps,res,h1,h2,pmask,vmult,1,1) >>> if (param(21).gt.0.and.tolps.gt.abs(param(21))) >>> $ tolps = abs(param(21)) >>> if (istep.eq.0) tolps = 1.e-4 >>> tolpss = tolps >>> c >>> iconv = 0 >>> call rzero(x,n) >>> >>> do while(iconv.eq.0.and.iter.lt.500) >>> >>> if(iter.eq.0) then ! -1 >>> call col3(r,ml,res,n) ! r = L res >>> c call copy(r,res,n) >>> else >>> !update residual >>> call copy (r,res,n) ! r = res >>> call ax (w,x,h1,h2,n) ! w = A x >>> call add2s2(r,w,-1.,n) ! r = r - w >>> ! -1 >>> call col2(r,ml,n) ! r = L r >>> endif >>> ! ______ >>> gamma(1) = sqrt(glsc3(r,r,wt,n)) ! gamma = \/ (r,r) >>> ! 1 >>> if(iter.eq.0) then >>> div0 = gamma(1)*norm_fac >>> if (param(21).lt.0) tolpss=abs(param(21))*div0 >>> endif >>> >>> !check for lucky convergence >>> rnorm = 0. >>> if(gamma(1) .eq. 0.) goto 9000 >>> temp = 1./gamma(1) >>> call cmult2(v(1,1),r,temp,n) ! v = r / gamma >>> ! 1 1 >>> do j=1,m >>> iter = iter+1 >>> ! -1 >>> call col3(w,mu,v(1,j),n) ! w = U v >>> ! j >>> >>> c . . . . . Overlapping Schwarz + coarse-grid . . . . . . . >>> >>> etime2 = dnekclock() >>> kfldfdm = ndim+1 >>> call fdm_h1 >>> $ (z(1,j),w,d,pmask,vmult,nelv,ktype(1,1,kfldfdm),wk) >>> call crs_solve_h1 (wk,w) c call >>> hsmg_solve(z(1,j),w) ! z = M w >>> ! j >>> call add2 (z(1,j),wk,n) >>> if (ifvcor) then >>> rmean = smean*glsc2(z(1,j),vmult,n) >>> call cadd(z(1,j),rmean,n) >>> endif >>> etime_p = etime_p + dnekclock()-etime2 >>> c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>> >>> >>> call ax (w,z(1,j),h1,h2,n) ! w = A z >>> ! j >>> >>> ! -1 >>> call col2(w,ml,n) ! w = L w >>> >>> c !modified Gram-Schmidt >>> >>> c do i=1,j >>> c h(i,j)=glsc3(w,v(1,i),wt,n) ! h = (w,v ) >>> c ! i,j i >>> >>> c call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v >>> c enddo ! i,j i >>> >>> c 2-PASS GS, 1st pass: >>> >>> do i=1,j >>> h(i,j)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) >>> enddo ! i,j i >>> >>> call gop(h(1,j),wk1,'+ ',j) ! sum over P procs >>> >>> do i=1,j >>> call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v >>> enddo ! i,j i >>> >>> >>> c 2-PASS GS, 2nd pass: >>> c >>> c do i=1,j >>> c wk1(i)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) >>> c enddo ! i,j i >>> c ! >>> c call gop(wk1,wk2,'+ ',j) ! sum over P procs >>> c >>> c do i=1,j >>> c call add2s2(w,v(1,i),-wk1(i),n) ! w = w - h v >>> c h(i,j) = h(i,j) + wk1(i) ! i,j i >>> c enddo >>> >>> !apply Givens rotations to new column >>> do i=1,j-1 >>> temp = h(i,j) >>> h(i ,j)= c(i)*temp + s(i)*h(i+1,j) >>> h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) >>> enddo >>> ! ______ >>> alpha = sqrt(glsc3(w,w,wt,n)) ! alpha = \/ (w,w) >>> rnorm = 0. >>> if(alpha.eq.0.) goto 900 !converged >>> l = sqrt(h(j,j)*h(j,j)+alpha*alpha) >>> temp = 1./l >>> c(j) = h(j,j) * temp >>> s(j) = alpha * temp >>> h(j,j) = l >>> gamma(j+1) = -s(j) * gamma(j) >>> gamma(j) = c(j) * gamma(j) >>> >>> rnorm = abs(gamma(j+1))*norm_fac >>> ratio = rnorm/div0 >>> if (ifprint.and.nid.eq.0) >>> $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep >>> 66 format(i5,1p4e12.5,i8,' Divergence') >>> >>> #ifndef TST_WSCAL >>> if (rnorm .lt. tolpss) goto 900 !converged >>> #else >>> if (iter.gt.param(151)-1) goto 900 >>> #endif >>> if (j.eq.m) goto 1000 !not converged, restart >>> >>> temp = 1./alpha >>> call cmult2(v(1,j+1),w,temp,n) ! v = w / alpha >>> ! j+1 >>> enddo >>> 900 iconv = 1 >>> 1000 continue >>> !back substitution >>> ! -1 >>> !c = H gamma >>> do k=j,1,-1 >>> temp = gamma(k) >>> do i=j,k+1,-1 >>> temp = temp - h(k,i)*c(i) >>> enddo >>> c(k) = temp/h(k,k) >>> enddo >>> !sum up Arnoldi vectors >>> do i=1,j >>> call add2s2(x,z(1,i),c(i),n) ! x = x + c z >>> enddo ! i i >>> c if(iconv.eq.1) call dbg_write(x,nx1,ny1,nz1,nelv,'esol',3) >>> enddo >>> 9000 continue >>> c >>> divex = rnorm >>> call copy(res,x,n) >>> c >>> if (ifvcor) then >>> xaver = glsc2(bm1,res,n)/volvm1 >>> call cadd(res,-xaver,n) >>> endif >>> c >>> etime1 = dnekclock()-etime1 >>> if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, >>> & etime1 >>> c call flush_hack >>> 9999 format(4X,I7,' PRES gmres: ',I6,1p5E13.4) >>> >>> return >>> end >>> c----------------------------------------------------------------------- >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sun Apr 25 14:21:29 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 25 Apr 2010 14:21:29 -0500 (CDT) Subject: [Nek5000-users] Residuals for post-processing In-Reply-To: <4BD47BD1.6020804@vt.edu> References: <4BCEF889.1050105@vt.edu> <4BD45A25.4040005@vt.edu> <4BD47BD1.6020804@vt.edu> Message-ID: Hi Markus, outpost simply provides a window towards generating .fld files. It's looking for 3 fields that will be interpreted as components of the vector field (vx,vy,vz) -- but obviously that field will contain only what is actually passed to it. 4th field is the pressure surrogate 5th field is the temperature surrogate. It's important if using pn-pn-2 that the pressure field look like a pressure field (the velocity and temp are pn, pressure is pn-2). Paul On Sun, 25 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > uh-oh, I think I misread your first response - your suggestion was to > include: > call outpost(x,y,z,res,t,'res') > call exitti('quit in gmres$',n) > in gmres.f, not in usrchk ? > > What do x,v,and z stand for? > > Thanks, > Markus > > > nek5000-users at lists.mcs.anl.gov wrote: >> >> >> Hi Markus, >> >> The issue here is that "res" is an argument passed into >> the gmres solver and is not the stored value that is held >> in GMRES, so a seg fault would be a natural failure. >> >> The stored values are x,r,v,and z. >> >> Paul >> >> >> On Sun, 25 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> this is what I added to usrchk: >>> --- >>> include 'GMRES' >>> if (istep.gt.0) then >>> call outpost(vx,vy,vz,res,t,'res') >>> call exitti('quit in gmres$',n) >>> endif >>> --- >>> Unfortunately, this causes the code to crash whenever outpost is called: >>> --- >>> 120 1.00000E-06 8.11690E-04 5.58247E-01 1.45400E-03 1 Divergence >>> 1 U-Pres gmres: 120 8.1169E-04 1.0000E-06 5.5825E-01 >>> 2.8286E+00 8.0148E+00 >>> 1 DNORM, DIVEX 0.35002708528548815 8.11690205515358640E-004 >>> 1 5.0000E-03 8.3137E+00 Fluid done >>> filt amp 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0125 0.0500 >>> filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.9875 0.9500 >>> ./nek: line 7: 11765 Segmentation fault (core dumped) ./nek5000 >>> >>> real 0m27.297s >>> user 0m9.348s >>> sys 0m1.124s >>> --- >>> >>> I tried with pr instead of res, that works. Is it possible that res is not >>> an array but a single number? >>> Where are the residuals for velocity and passive scalars stored? >>> >>> I added the divergence procedure to the outflow, there is no back flow. >>> The problem is not that the simulation blows up (at least for the time >>> steps I am doing), it is that the pressure residuals don't fall below the >>> specified limit when I increase lx1. This is for both PN/PN-2 and PN/PN >>> and not a function of dt. >>> >>> Thanks, >>> Markus >>> >>> >>> >>> nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>> Hi Markus, >>>> >>>> pressure residuals are in gmres >>>> >>>> You could output them via: >>>> >>>> call outpost(x,y,z,res,t,'res') >>>> >>>> where x,y,z,t are arrays of your choice and res >>>> is the array you want to look at. >>>> >>>> Nek will convert the res mesh to the velocity mesh >>>> if needed. I usually follow such a call with >>>> >>>> call exitti('quit in gmres$',n) >>>> >>>> because prepost() uses some scratch common blocks >>>> that are potentially shared with the calling routine >>>> (not in the case of gmres, I think...) -- so data might be corrupted >>>> after such a call. The idea of >>>> prepost was to be called in between timesteps, when >>>> such memory re-use would be admissable. The alternative >>>> would be to define your own storage in a common block, >>>> save the residuals to this locale, then loop through >>>> calls to outpost in userchk afterwards... I've done >>>> that in the past. >>>> >>>> All this being said, I'm not 100% certain that the >>>> iterative solvers is the place to look for the difficulty. >>>> Most problems arise from spatial resolution issues...or >>>> temporal stability problems. The latter can be identified >>>> by drastic reduction in dt. >>>> >>>> What exactly is blowing up for you? >>>> >>>> Paul >>>> >>>> >>>> On Wed, 21 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi, >>>>> >>>>> I'd like to save the residuals for the pressure iterations (PN/PN-2 as >>>>> well as PN/PN) into a scalar variable (scalar 0, instead of temperature >>>>> say) for each grid point in order to see where my solution diverges. >>>>> Is there a way to add something to the .usr file to do that? I couldn't >>>>> find the variable in the code and also wouldn't know how to save >>>>> something from the lx2=lx1-2 grid onto the lx1 grid. >>>>> Would this also be possible with the velocity residuals? >>>>> >>>>> Thanks, >>>>> Markus >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>> >>>> uuuu >>>> c----------------------------------------------------------------------- >>>> subroutine uzawa_gmres(res,h1,h2,h2inv,intype,iter) >>>> >>>> c Solve the pressure equation by right-preconditioned c GMRES >>>> iteration. >>>> c intype = 0 (steady) >>>> c intype = 1 (explicit) >>>> c intype = -1 (implicit) >>>> >>>> include 'SIZE' >>>> include 'TOTAL' >>>> include 'GMRES' >>>> common /ctolpr/ divex >>>> common /cprint/ ifprint >>>> logical ifprint >>>> real res (lx2*ly2*lz2*lelv) >>>> real h1 (lx1,ly1,lz1,lelv) >>>> real h2 (lx1,ly1,lz1,lelv) >>>> real h2inv(lx1,ly1,lz1,lelv) >>>> >>>> common /scrmg/ wp (lx2,ly2,lz2,lelv) >>>> >>>> common /ctmp0/ wk1(lgmres),wk2(lgmres) >>>> common /cgmres1/ y(lgmres) >>>> >>>> real alpha, l, temp >>>> integer j,m >>>> c >>>> logical iflag >>>> save iflag >>>> data iflag /.false./ >>>> real norm_fac >>>> save norm_fac >>>> c >>>> real*8 etime1,dnekclock >>>> c >>>> if(.not.iflag) then >>>> iflag=.true. >>>> call uzawa_gmres_split0(ml,mu,bm2,bm2inv,nx2*ny2*nz2*nelv) >>>> norm_fac = 1./sqrt(volvm2) >>>> endif >>>> c >>>> etime1 = dnekclock() >>>> etime_p = 0. >>>> divex = 0. >>>> iter = 0 >>>> m = lgmres >>>> c >>>> call chktcg2(tolps,res,iconv) >>>> if (param(21).gt.0.and.tolps.gt.abs(param(21))) >>>> $ tolps = abs(param(21)) >>>> c if (param(21).lt.0) tolps = abs(param(21)) >>>> if (istep.eq.0) tolps = 1.e-4 >>>> tolpss = tolps >>>> c >>>> ntot2 = nx2*ny2*nz2*nelv >>>> c >>>> iconv = 0 >>>> call rzero(x,ntot2) >>>> >>>> do while(iconv.eq.0.and.iter.lt.100) >>>> >>>> if(iter.eq.0) then >>>> ! -1 >>>> call col3(r,ml,res,ntot2) ! r = L res >>>> c call copy(r,res,ntot2) >>>> else >>>> !update residual >>>> call copy(r,res,ntot2) ! r = res >>>> call cdabdtp(w,x,h1,h2,h2inv,intype) ! w = A x >>>> call add2s2(r,w,-1.,ntot2) ! r = r - w >>>> ! -1 >>>> call col2(r,ml,ntot2) ! r = L r >>>> endif >>>> ! ______ >>>> gamma(1) = sqrt(glsc2(r,r,ntot2)) ! gamma = \/ (r,r) >>>> ! 1 >>>> if(iter.eq.0) then >>>> div0 = gamma(1)*norm_fac >>>> if (param(21).lt.0) tolpss=abs(param(21))*div0 >>>> endif >>>> >>>> !check for lucky convergence >>>> rnorm = 0. >>>> if(gamma(1) .eq. 0.) goto 9000 >>>> temp = 1./gamma(1) >>>> call cmult2(v(1,1),r,temp,ntot2) ! v = r / gamma >>>> ! 1 1 >>>> do j=1,m >>>> iter = iter+1 >>>> ! -1 >>>> call col3(w,mu,v(1,j),ntot2) ! w = U v >>>> ! j >>>> >>>> etime2 = dnekclock() >>>> if(param(43).eq.1) then >>>> call uzprec(z(1,j),w,h1,h2,intype,wp) >>>> else ! -1 >>>> call hsmg_solve(z(1,j),w) ! z = M w >>>> endif >>>> etime_p = etime_p + dnekclock()-etime2 >>>> >>>> call cdabdtp(w,z(1,j), ! w = A z >>>> $ h1,h2,h2inv,intype) ! j >>>> >>>> ! -1 >>>> call col2(w,ml,ntot2) ! w = L w >>>> >>>> c !modified Gram-Schmidt >>>> c do i=1,j >>>> c h(i,j)=glsc2(w,v(1,i),ntot2) ! h = (w,v ) >>>> c ! i,j i >>>> c call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v >>>> c enddo ! i,j i >>>> >>>> >>>> c 2-PASS GS, 1st pass: >>>> >>>> do i=1,j >>>> h(i,j)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) >>>> enddo ! i,j i >>>> >>>> call gop(h(1,j),wk1,'+ ',j) ! sum over P procs >>>> >>>> do i=1,j >>>> call add2s2(w,v(1,i),-h(i,j),ntot2)! w = w - h v >>>> enddo ! i,j i >>>> >>>> >>>> c 2-PASS GS, 2nd pass: >>>> c >>>> c do i=1,j >>>> c wk1(i)=vlsc2(w,v(1,i),ntot2) ! h = (w,v ) >>>> c enddo ! i,j i >>>> c ! >>>> c call gop(wk1,wk2,'+ ',j) ! sum over P procs >>>> c >>>> c do i=1,j >>>> c call add2s2(w,v(1,i),-wk1(i),ntot2)! w = w - h v >>>> c h(i,j) = h(i,j) + wk1(i) ! i,j i >>>> c enddo >>>> >>>> >>>> !apply Givens rotations to new column >>>> do i=1,j-1 >>>> temp = h(i,j) >>>> h(i ,j)= c(i)*temp + s(i)*h(i+1,j) >>>> h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) >>>> enddo >>>> ! ______ >>>> alpha = sqrt(glsc2(w,w,ntot2)) ! alpha = \/ (w,w) >>>> rnorm = 0. >>>> if(alpha.eq.0.) goto 900 !converged >>>> l = sqrt(h(j,j)*h(j,j)+alpha*alpha) >>>> temp = 1./l >>>> c(j) = h(j,j) * temp >>>> s(j) = alpha * temp >>>> h(j,j) = l >>>> gamma(j+1) = -s(j) * gamma(j) >>>> gamma(j) = c(j) * gamma(j) >>>> >>>> c call outmat(h,m,j,' h ',j) >>>> >>>> rnorm = abs(gamma(j+1))*norm_fac >>>> ratio = rnorm/div0 >>>> if (ifprint.and.nid.eq.0) >>>> $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep >>>> 66 format(i5,1p4e12.5,i8,' Divergence') >>>> >>>> #ifndef TST_WSCAL >>>> if (rnorm .lt. tolpss) goto 900 !converged >>>> #else >>>> if (iter.gt.param(151)-1) goto 900 >>>> #endif >>>> if (j.eq.m) goto 1000 !not converged, restart >>>> >>>> temp = 1./alpha >>>> call cmult2(v(1,j+1),w,temp,ntot2) ! v = w / alpha >>>> ! j+1 >>>> enddo >>>> 900 iconv = 1 >>>> 1000 continue >>>> !back substitution >>>> ! -1 >>>> !c = H gamma >>>> do k=j,1,-1 >>>> temp = gamma(k) >>>> do i=j,k+1,-1 >>>> temp = temp - h(k,i)*c(i) >>>> enddo >>>> c(k) = temp/h(k,k) >>>> enddo >>>> !sum up Arnoldi vectors >>>> do i=1,j >>>> call add2s2(x,z(1,i),c(i),ntot2) ! x = x + c z >>>> ! i i >>>> enddo >>>> c if(iconv.eq.1) call dbg_write(x,nx2,ny2,nz2,nelv,'esol',3) >>>> enddo >>>> 9000 continue >>>> c >>>> divex = rnorm >>>> c iter = iter - 1 >>>> c >>>> c DIAGNOSTICS >>>> c call copy(w,x,ntot2) >>>> c if (ifvcor) then >>>> c xaver = glsc2(bm2,w,ntot2)/volvm2 >>>> c call cadd(w,-xaver,ntot2) >>>> c endif >>>> c call copy(r,res,ntot2) !r = res >>>> c call cdabdtp(r,w,h1,h2,h2inv,intype) ! r = A w >>>> c do i=1,ntot2 >>>> c r(i) = res(i) - r(i) ! r = res - r >>>> c enddo >>>> c call uzawa_gmres_temp(r,bm2inv,ntot2) >>>> c ! ______ >>>> c gamma(1) = sqrt(glsc2(r,r,ntot2)/volvm2) ! gamma = \/ (r,r) c ! >>>> 1 >>>> c print *, 'GMRES end resid:',gamma(1) >>>> c END DIAGNOSTICS >>>> call copy(res,x,ntot2) >>>> c >>>> if (ifvcor) then >>>> xaver = glsc2(bm2,res,ntot2)/volvm2 >>>> call cadd(res,-xaver,ntot2) >>>> endif >>>> c >>>> etime1 = dnekclock()-etime1 >>>> if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, >>>> & etime1 >>>> c call flush_hack >>>> 9999 format(4X,I7,' U-Pres gmres: ',I6,1p5E13.4) >>>> c >>>> c >>>> return >>>> end >>>> >>>> c----------------------------------------------------------------------- >>>> >>>> subroutine uzawa_gmres_split0(l,u,b,binv,n) >>>> integer n >>>> real l(n),u(n),b(n),binv(n) >>>> integer i >>>> do i=1,n >>>> l(i)=sqrt(binv(i)) >>>> u(i)=sqrt(b(i)) >>>> if(abs(u(i)*l(i)-1.0).gt.1e-13) print *, i, u(i)*l(i) >>>> enddo >>>> return >>>> end >>>> >>>> c----------------------------------------------------------------------- >>>> subroutine uzawa_gmres_split(l,u,b,binv,n) >>>> integer n >>>> real l(n),u(n),b(n),binv(n) >>>> integer i >>>> do i=1,n >>>> c l(i)=sqrt(binv(i)) >>>> c u(i)=sqrt(b(i)) >>>> >>>> c u(i)=sqrt(b(i)) >>>> c l(i)=1./u(i) >>>> >>>> c l(i)=sqrt(binv(i)) >>>> l(i)=1. >>>> u(i)=1./l(i) >>>> >>>> >>>> c if(abs(u(i)*l(i)-1.0).gt.1e-13)write(6,*) i,u(i)*l(i),' gmr_sp' >>>> enddo >>>> return >>>> end >>>> >>>> c----------------------------------------------------------------------- >>>> subroutine uzawa_gmres_temp(a,b,n) >>>> integer n >>>> real a(n),b(n) >>>> integer i >>>> do i=1,n >>>> a(i)=sqrt(b(i))*a(i) >>>> enddo >>>> return >>>> end >>>> c----------------------------------------------------------------------- >>>> subroutine ax(w,x,h1,h2,n) >>>> include 'SIZE' >>>> include 'TOTAL' >>>> >>>> c >>>> c w = A*x for pressure iteration >>>> c >>>> >>>> integer n >>>> real w(n),x(n),h1(n),h2(n) >>>> >>>> imsh = 1 >>>> isd = 1 >>>> call axhelm (w,x,h1,h2,imsh,isd) >>>> call dssum (w,nx1,ny1,nz1) >>>> call col2 (w,pmask,n) >>>> >>>> return >>>> end >>>> c----------------------------------------------------------------------- >>>> subroutine hmh_gmres(res,h1,h2,wt,iter) >>>> >>>> c Solve the Helmholtz equation by right-preconditioned c GMRES >>>> iteration. >>>> >>>> >>>> include 'SIZE' >>>> include 'TOTAL' >>>> include 'FDMH1' >>>> include 'GMRES' >>>> common /ctolpr/ divex >>>> common /cprint/ ifprint >>>> logical ifprint >>>> real res (lx1*ly1*lz1*lelv) >>>> real h1 (lx1,ly1,lz1,lelv) >>>> real h2 (lx1,ly1,lz1,lelv) >>>> real wt (lx1,ly1,lz1,lelv) >>>> >>>> common /scrcg/ d(lx1*ly1*lz1*lelv),wk(lx1*ly1*lz1*lelv) >>>> >>>> common /cgmres1/ y(lgmres) >>>> common /ctmp0/ wk1(lgmres),wk2(lgmres) >>>> real alpha, l, temp >>>> integer j,m >>>> >>>> logical iflag >>>> save iflag >>>> data iflag /.false./ >>>> real norm_fac >>>> save norm_fac >>>> >>>> real*8 etime1,dnekclock >>>> >>>> >>>> n = nx1*ny1*nz1*nelv >>>> >>>> etime1 = dnekclock() >>>> etime_p = 0. >>>> divex = 0. >>>> iter = 0 >>>> m = lgmres >>>> >>>> if(.not.iflag) then >>>> iflag=.true. >>>> call uzawa_gmres_split(ml,mu,bm1,binvm1,nx1*ny1*nz1*nelv) >>>> norm_fac = 1./sqrt(volvm1) >>>> endif >>>> >>>> call set_fdm_prec_h1b(d,h1,h2,nelv) >>>> if (ifvcor) smean = -1./glsum(vmult,n) >>>> >>>> call chktcg1(tolps,res,h1,h2,pmask,vmult,1,1) >>>> if (param(21).gt.0.and.tolps.gt.abs(param(21))) >>>> $ tolps = abs(param(21)) >>>> if (istep.eq.0) tolps = 1.e-4 >>>> tolpss = tolps >>>> c >>>> iconv = 0 >>>> call rzero(x,n) >>>> >>>> do while(iconv.eq.0.and.iter.lt.500) >>>> >>>> if(iter.eq.0) then ! -1 >>>> call col3(r,ml,res,n) ! r = L res >>>> c call copy(r,res,n) >>>> else >>>> !update residual >>>> call copy (r,res,n) ! r = res >>>> call ax (w,x,h1,h2,n) ! w = A x >>>> call add2s2(r,w,-1.,n) ! r = r - w >>>> ! -1 >>>> call col2(r,ml,n) ! r = L r >>>> endif >>>> ! ______ >>>> gamma(1) = sqrt(glsc3(r,r,wt,n)) ! gamma = \/ (r,r) >>>> ! 1 >>>> if(iter.eq.0) then >>>> div0 = gamma(1)*norm_fac >>>> if (param(21).lt.0) tolpss=abs(param(21))*div0 >>>> endif >>>> >>>> !check for lucky convergence >>>> rnorm = 0. >>>> if(gamma(1) .eq. 0.) goto 9000 >>>> temp = 1./gamma(1) >>>> call cmult2(v(1,1),r,temp,n) ! v = r / gamma >>>> ! 1 1 >>>> do j=1,m >>>> iter = iter+1 >>>> ! -1 >>>> call col3(w,mu,v(1,j),n) ! w = U v >>>> ! j >>>> >>>> c . . . . . Overlapping Schwarz + coarse-grid . . . . . . . >>>> >>>> etime2 = dnekclock() >>>> kfldfdm = ndim+1 >>>> call fdm_h1 >>>> $ (z(1,j),w,d,pmask,vmult,nelv,ktype(1,1,kfldfdm),wk) >>>> call crs_solve_h1 (wk,w) c call >>>> hsmg_solve(z(1,j),w) ! z = M w >>>> ! j >>>> call add2 (z(1,j),wk,n) >>>> if (ifvcor) then >>>> rmean = smean*glsc2(z(1,j),vmult,n) >>>> call cadd(z(1,j),rmean,n) >>>> endif >>>> etime_p = etime_p + dnekclock()-etime2 >>>> c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >>>> >>>> >>>> call ax (w,z(1,j),h1,h2,n) ! w = A z >>>> ! j >>>> >>>> ! -1 >>>> call col2(w,ml,n) ! w = L w >>>> >>>> c !modified Gram-Schmidt >>>> >>>> c do i=1,j >>>> c h(i,j)=glsc3(w,v(1,i),wt,n) ! h = (w,v ) >>>> c ! i,j i >>>> >>>> c call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v >>>> c enddo ! i,j i >>>> >>>> c 2-PASS GS, 1st pass: >>>> >>>> do i=1,j >>>> h(i,j)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) >>>> enddo ! i,j i >>>> >>>> call gop(h(1,j),wk1,'+ ',j) ! sum over P procs >>>> >>>> do i=1,j >>>> call add2s2(w,v(1,i),-h(i,j),n) ! w = w - h v >>>> enddo ! i,j i >>>> >>>> >>>> c 2-PASS GS, 2nd pass: >>>> c >>>> c do i=1,j >>>> c wk1(i)=vlsc3(w,v(1,i),wt,n) ! h = (w,v ) >>>> c enddo ! i,j i >>>> c ! >>>> c call gop(wk1,wk2,'+ ',j) ! sum over P procs >>>> c >>>> c do i=1,j >>>> c call add2s2(w,v(1,i),-wk1(i),n) ! w = w - h v >>>> c h(i,j) = h(i,j) + wk1(i) ! i,j i >>>> c enddo >>>> >>>> !apply Givens rotations to new column >>>> do i=1,j-1 >>>> temp = h(i,j) >>>> h(i ,j)= c(i)*temp + s(i)*h(i+1,j) >>>> h(i+1,j)= -s(i)*temp + c(i)*h(i+1,j) >>>> enddo >>>> ! ______ >>>> alpha = sqrt(glsc3(w,w,wt,n)) ! alpha = \/ (w,w) >>>> rnorm = 0. >>>> if(alpha.eq.0.) goto 900 !converged >>>> l = sqrt(h(j,j)*h(j,j)+alpha*alpha) >>>> temp = 1./l >>>> c(j) = h(j,j) * temp >>>> s(j) = alpha * temp >>>> h(j,j) = l >>>> gamma(j+1) = -s(j) * gamma(j) >>>> gamma(j) = c(j) * gamma(j) >>>> >>>> rnorm = abs(gamma(j+1))*norm_fac >>>> ratio = rnorm/div0 >>>> if (ifprint.and.nid.eq.0) >>>> $ write (6,66) iter,tolpss,rnorm,div0,ratio,istep >>>> 66 format(i5,1p4e12.5,i8,' Divergence') >>>> >>>> #ifndef TST_WSCAL >>>> if (rnorm .lt. tolpss) goto 900 !converged >>>> #else >>>> if (iter.gt.param(151)-1) goto 900 >>>> #endif >>>> if (j.eq.m) goto 1000 !not converged, restart >>>> >>>> temp = 1./alpha >>>> call cmult2(v(1,j+1),w,temp,n) ! v = w / alpha >>>> ! j+1 >>>> enddo >>>> 900 iconv = 1 >>>> 1000 continue >>>> !back substitution >>>> ! -1 >>>> !c = H gamma >>>> do k=j,1,-1 >>>> temp = gamma(k) >>>> do i=j,k+1,-1 >>>> temp = temp - h(k,i)*c(i) >>>> enddo >>>> c(k) = temp/h(k,k) >>>> enddo >>>> !sum up Arnoldi vectors >>>> do i=1,j >>>> call add2s2(x,z(1,i),c(i),n) ! x = x + c z >>>> enddo ! i i >>>> c if(iconv.eq.1) call dbg_write(x,nx1,ny1,nz1,nelv,'esol',3) >>>> enddo >>>> 9000 continue >>>> c >>>> divex = rnorm >>>> call copy(res,x,n) >>>> c >>>> if (ifvcor) then >>>> xaver = glsc2(bm1,res,n)/volvm1 >>>> call cadd(res,-xaver,n) >>>> endif >>>> c >>>> etime1 = dnekclock()-etime1 >>>> if (nid.eq.0) write(6,9999) istep,iter,divex,tolpss,div0,etime_p, >>>> & etime1 >>>> c call flush_hack >>>> 9999 format(4X,I7,' PRES gmres: ',I6,1p5E13.4) >>>> >>>> return >>>> end >>>> c----------------------------------------------------------------------- >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Apr 26 04:34:08 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Apr 2010 11:34:08 +0200 Subject: [Nek5000-users] connect1.f In-Reply-To: <298E357E-C9A3-470E-A689-645B59EDA75B@lav.mavt.ethz.ch> References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> <4BD04791.2030503@gmail.com> <298E357E-C9A3-470E-A689-645B59EDA75B@lav.mavt.ethz.ch> Message-ID: <4BD55E10.109@mech.kth.se> Dear Paul and Stefan, This morning I updated my code to the newest version, r493. The compilation failed in connect1.f . I guess the following line is missing there: 1622d1621 < parameter(lxz=lx1*lz1) 1630c1629 < --- > Is that correct? Thank you, and greetings from KTH Stockholm, Lars-Uve. -- Lars-Uve Schrader KTH Mechanics SE-100 44 Stockholm Sweden www.mech.kth.se From nek5000-users at lists.mcs.anl.gov Mon Apr 26 06:15:54 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Apr 2010 06:15:54 -0500 (CDT) Subject: [Nek5000-users] connect1.f In-Reply-To: <4BD55E10.109@mech.kth.se> References: <4BD00D3C.4090809@gmail.com> <4BD04472.2010505@gmail.com> <4BD04791.2030503@gmail.com> <298E357E-C9A3-470E-A689-645B59EDA75B@lav.mavt.ethz.ch> <4BD55E10.109@mech.kth.se> Message-ID: Dear Lars-Uve, Sorry about that - you need to add this to your SIZE file. (All examples now have this.) Paul On Mon, 26 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul and Stefan, > > > This morning I updated my code to the newest version, r493. The compilation > failed in connect1.f . > I guess the following line is missing there: > > 1622d1621 > < parameter(lxz=lx1*lz1) > 1630c1629 > < > --- >> > > Is that correct? > > > Thank you, > and greetings from KTH Stockholm, > > > Lars-Uve. > > > -- > Lars-Uve Schrader > KTH Mechanics > SE-100 44 Stockholm > Sweden > www.mech.kth.se > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Apr 26 07:51:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Apr 2010 14:51:44 +0200 Subject: [Nek5000-users] Stretching ratio Message-ID: <4BD58C60.4070909@kit.edu> Dear NEKs, when using non-uniform grids, is there any threshold/maximum for the stretching ration of size of one element to an other?? Best, Fred From nek5000-users at lists.mcs.anl.gov Mon Apr 26 08:37:20 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Apr 2010 08:37:20 -0500 (CDT) Subject: [Nek5000-users] Stretching ratio In-Reply-To: <4BD58C60.4070909@kit.edu> References: <4BD58C60.4070909@kit.edu> Message-ID: In general, the answer is no. It does matter, however, whether you are stretching the input grid (i.e., at some point prior to the simulation) or are stretching the geometry (xm1,ym1,zm1) in usrdat2. In the latter case it's rather important to stick with linear maps of the form: x' = a x + b ... Otherwise you end up changing the spacing of the Gauss-Lobatto-Legendre points within the element and this can lead to stability problems (e.g. a non-positive mass matrix). When stretching the mesh (i.e., the originating SE vertices), you of course want to resolve regions of interest, subject to the consideration that very small mesh spacing can lead to CFL timestep constraints if the velocity is nonzero in those regions. Paul On Mon, 26 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear NEKs, > > when using non-uniform grids, is there any threshold/maximum for the > stretching ration of size of one element to an other?? > > Best, Fred > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Apr 26 15:07:30 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Apr 2010 15:07:30 -0500 Subject: [Nek5000-users] Odd lx1 numbers & lxd Message-ID: Hello, I have a question about lx1 and de-aliasing. Is it OK to have odd number as lx1 ? If yes, in such cases one might violate the 3/2 rule for lxd . Or only even numbers are recommended ? Thanks Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 26 15:14:19 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 26 Apr 2010 15:14:19 -0500 (CDT) Subject: [Nek5000-users] Odd lx1 numbers & lxd In-Reply-To: References: Message-ID: As long as lxd ~ 3/2 lx1, you're generally ok. lx1 and lxd being odd is very bad for certain platforms (right now, the only one is BG/P or BG/L). On these platforms it is possible to get much higher performance for even lx1, lxd, etc. Paul On Mon, 26 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I have a question about lx1 and de-aliasing. Is it OK to have odd number as > lx1 ? If yes, in such cases one might violate the 3/2 rule for lxd . > Or only even numbers are recommended ? > > Thanks > Shriram > From nek5000-users at lists.mcs.anl.gov Tue Apr 27 16:27:47 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 Apr 2010 16:27:47 -0500 Subject: [Nek5000-users] History Points Message-ID: Hello, I would like to know the general procedure that is recommended for inserting history points. I have close to 200 points and its a bit cumbersome to manually click on each of these points, although I got it to work that way. Is there a way to do it by giving just the coordinates ? And on the log file, nek throws the coordinates of history points randomly, for ex. coordinates of point 1 might come after point 140. Regards Shriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 27 16:50:11 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 Apr 2010 16:50:11 -0500 (CDT) Subject: [Nek5000-users] History Points In-Reply-To: Message-ID: <13076399.685421272405011332.JavaMail.root@zimbra> Hi Paul, Yes to both -- I do see these email (I once even answered one :), and the interpolation routines written by James (JL/*) and Stepan (postnek.f) are part of the current repo. For not very large problems Stephan's wiki example works fine -- memory allocation becomes an issue on BG/P with ~ 40,000 elements (upper bound). I am hoping to fix it once we are done with T-junction... Cheers, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Tuesday, April 27, 2010 4:27:47 PM GMT -06:00 US/Canada Central Subject: [Nek5000-users] History Points Hello, I would like to know the general procedure that is recommended for inserting history points. I have close to 200 points and its a bit cumbersome to manually click on each of these points, although I got it to work that way. Is there a way to do it by giving just the coordinates ? And on the log file, nek throws the coordinates of history points randomly, for ex. coordinates of point 1 might come after point 140. Regards Shriram _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Apr 27 17:01:14 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 27 Apr 2010 17:01:14 -0500 (CDT) Subject: [Nek5000-users] History Points In-Reply-To: Message-ID: <20024116.685641272405674103.JavaMail.root@zimbra> Hi Shriram, You can try a wiki example https://nek5000.mcs.anl.gov/index.php/Data_processing_example which works fine for not very large problems. Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Tuesday, April 27, 2010 4:27:47 PM GMT -06:00 US/Canada Central Subject: [Nek5000-users] History Points Hello, I would like to know the general procedure that is recommended for inserting history points. I have close to 200 points and its a bit cumbersome to manually click on each of these points, although I got it to work that way. Is there a way to do it by giving just the coordinates ? And on the log file, nek throws the coordinates of history points randomly, for ex. coordinates of point 1 might come after point 140. Regards Shriram _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Apr 27 23:41:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Apr 2010 00:41:21 -0400 Subject: [Nek5000-users] De-Aliasing for passive scalar Message-ID: <4BD7BC71.60201@vt.edu> Hi, since I am doing heat transfer simulations, I was wondering if the passive scalar (heat) equation is also subject to de-aliasing? If so, is this done with the same parameters as the momentum? Thanks, Markus From nek5000-users at lists.mcs.anl.gov Wed Apr 28 00:43:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Apr 2010 00:43:41 -0500 (CDT) Subject: [Nek5000-users] De-Aliasing for passive scalar In-Reply-To: <4BD7BC71.60201@vt.edu> References: <4BD7BC71.60201@vt.edu> Message-ID: Yes - same for both. Paul On Wed, 28 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > since I am doing heat transfer simulations, I was wondering if the passive > scalar (heat) equation is also subject to de-aliasing? If so, is this done > with the same parameters as the momentum? > > Thanks, > Markus > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Apr 28 03:13:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Apr 2010 10:13:44 +0200 Subject: [Nek5000-users] Tolerances In-Reply-To: References: Message-ID: <4BD7EE38.6060809@mech.kth.se> Dear Paul and Stefan, We are currently studying a 3D flat-plate boundary layer which is highly unstable to crossflow modes. When computing the base flow we realize that numerical noise already triggers unsteady crossflow waves with amplitudes of the order of 10^{-6}. We plan to study receptivity to external perturbations with amplitudes of 10^{-5} (to avoid early nonlinearity) so it would be desirable to suppress the numerically triggered disturbance waves. We use the PN-PN-2 formulation, dealiasing and filtering (0.05). We also noticed that about 15 pressure iterations per timestep (gmres) were needed which seems to be high. We further use the following tolerances: 1.0E-08 DIVERGENCE 1.0E-08 HELMHOLTZ 1.0E-06 TOLREL 1.0E-10 TOLABS We wonder whether using stricter values may lead to smoother results. What is actually the meaning of TOLREL and TOLABS? Thank you very much for your advice and some clarification. Greetings from KTH Stockholm, Lars-Uve and David From nek5000-users at lists.mcs.anl.gov Wed Apr 28 05:39:36 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Apr 2010 12:39:36 +0200 Subject: [Nek5000-users] Tolerances In-Reply-To: <4BD7EE38.6060809@mech.kth.se> References: <4BD7EE38.6060809@mech.kth.se> Message-ID: <0D6667A2-88F9-4DAE-BAA9-BC9EC5F76852@lav.mavt.ethz.ch> Do you really think 15 pressure iterations are too much? Considering you strict tolerance I would say it's pretty good! I am not sure what triggers your noise but did you try to use a high resolution? In your case TOLREL/TOLABS are not important! The tolerance you specify in DIVERGENCE is for the pressure solver. In fact if you use the PN/PN_2 scheme you'll end up with a divergence of the velocity which is comparable to DIVERGENCE. The pressure solve projects the velocity on a divergence free space. and you can control the divergence by varying the pressure tolerance (that's why we call it DIVERGENCE). In the PN/PN scheme things are different. The HELMHOLTZ controls the tolerance for all Helmholtz solves so if you don't have any passive scalars it's just for the velocity. Stefan On Apr 28, 2010, at 10:13 AM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul and Stefan, > > We are currently studying a 3D flat-plate boundary layer which is highly unstable to crossflow modes. When computing the base flow we realize that numerical noise already triggers unsteady crossflow waves with amplitudes of the order of 10^{-6}. We plan to study receptivity to external perturbations with amplitudes of 10^{-5} (to avoid early nonlinearity) so it would be desirable to suppress the numerically triggered disturbance waves. > > We use the PN-PN-2 formulation, dealiasing and filtering (0.05). We also noticed that about 15 pressure iterations per timestep (gmres) were needed which seems to be high. > > We further use the following tolerances: > 1.0E-08 DIVERGENCE > 1.0E-08 HELMHOLTZ > > 1.0E-06 TOLREL > 1.0E-10 TOLABS > > We wonder whether using stricter values may lead to smoother results. What is actually the meaning of TOLREL and TOLABS? > > Thank you very much for your advice and some clarification. > > Greetings from KTH Stockholm, > > Lars-Uve and David > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 28 07:02:35 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Apr 2010 07:02:35 -0500 (CDT) Subject: [Nek5000-users] Tolerances In-Reply-To: <0D6667A2-88F9-4DAE-BAA9-BC9EC5F76852@lav.mavt.ethz.ch> Message-ID: <29089379.693401272456155677.JavaMail.root@zimbra> Hi Lars-Uve and David, I have been recently looking at the Rayleigh inviscid instability in 2D Navier-Stokes with Nek5000. A combination of higher resolution and tighter DIVERGENCE/HELMHOLTZ tolerances (1e-10/1e-11) did the trick... Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Wednesday, April 28, 2010 5:39:36 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Tolerances Do you really think 15 pressure iterations are too much? Considering you strict tolerance I would say it's pretty good! I am not sure what triggers your noise but did you try to use a high resolution? In your case TOLREL/TOLABS are not important! The tolerance you specify in DIVERGENCE is for the pressure solver. In fact if you use the PN/PN_2 scheme you'll end up with a divergence of the velocity which is comparable to DIVERGENCE. The pressure solve projects the velocity on a divergence free space. and you can control the divergence by varying the pressure tolerance (that's why we call it DIVERGENCE). In the PN/PN scheme things are different. The HELMHOLTZ controls the tolerance for all Helmholtz solves so if you don't have any passive scalars it's just for the velocity. Stefan On Apr 28, 2010, at 10:13 AM, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul and Stefan, > > We are currently studying a 3D flat-plate boundary layer which is highly unstable to crossflow modes. When computing the base flow we realize that numerical noise already triggers unsteady crossflow waves with amplitudes of the order of 10^{-6}. We plan to study receptivity to external perturbations with amplitudes of 10^{-5} (to avoid early nonlinearity) so it would be desirable to suppress the numerically triggered disturbance waves. > > We use the PN-PN-2 formulation, dealiasing and filtering (0.05). We also noticed that about 15 pressure iterations per timestep (gmres) were needed which seems to be high. > > We further use the following tolerances: > 1.0E-08 DIVERGENCE > 1.0E-08 HELMHOLTZ > > 1.0E-06 TOLREL > 1.0E-10 TOLABS > > We wonder whether using stricter values may lead to smoother results. What is actually the meaning of TOLREL and TOLABS? > > Thank you very much for your advice and some clarification. > > Greetings from KTH Stockholm, > > Lars-Uve and David > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed Apr 28 07:06:49 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Apr 2010 07:06:49 -0500 (CDT) Subject: [Nek5000-users] Tolerances In-Reply-To: <4BD7EE38.6060809@mech.kth.se> References: <4BD7EE38.6060809@mech.kth.se> Message-ID: tolrel and tolabs are ineffective when divergence/helmholtz are nonzero (i.e., they over-ride). tolrel determines conv. criteria based on eigenvalue estimates and magnitude of data (hence "rel" for relative). When tolrel is in effect, tolabs is ineffective. tolabs is like tolrel except it works when nek can't determine the magnitude (i.e., somehow all "observable" data is zero, where observable is to be interpreted as the data that tolrel has been designed to trigger off of). Typically I prefer div/hmh for problems that are nondimensional by convective time scales (i.e., where visc == 1/Re). In those cases, 1.e-6 for div and 1.e-8 for hmh are pretty good for most apps. Exceptions are stability problems or convergence studies, where tighter tolerances are desirable. Most likely you can't go too far wrong w/ tolrel=1.e-9 and hmh/div=0, though I find tolrel is a bit conservative. (Incidentally, engineering tolerances for tolrel would typically be 1.e-2, and would be very satisfactory -- in fact a bit more conservative than the 1.e-6/1.e-8 figures of the preceding paragraph.) The other option would be to set div=1.e-9, hmh=1.e-10 or 11. Assuming you're working in convective timescales, these should be adequate for your stability problem. 15 iterations doesn't seem to be a lot --- One question, do you have dt fixed (param 12 < 0), and p93, 94, 95 > 0 ? The latter control the pressure / velocity projection, which can greatly accelerate performance, esp. for tight tolerances. It is most effective when dt = constant. hth, Paul On Wed, 28 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul and Stefan, > > We are currently studying a 3D flat-plate boundary layer which is highly > unstable to crossflow modes. When computing the base flow we realize that > numerical noise already triggers unsteady crossflow waves with amplitudes of > the order of 10^{-6}. We plan to study receptivity to external perturbations > with amplitudes of 10^{-5} (to avoid early nonlinearity) so it would be > desirable to suppress the numerically triggered disturbance waves. > > We use the PN-PN-2 formulation, dealiasing and filtering (0.05). We also > noticed that about 15 pressure iterations per timestep (gmres) were needed > which seems to be high. > > We further use the following tolerances: > 1.0E-08 DIVERGENCE > 1.0E-08 HELMHOLTZ > > 1.0E-06 TOLREL > 1.0E-10 TOLABS > > We wonder whether using stricter values may lead to smoother results. What is > actually the meaning of TOLREL and TOLABS? > > Thank you very much for your advice and some clarification. > > Greetings from KTH Stockholm, > > Lars-Uve and David > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Wed Apr 28 07:59:46 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Apr 2010 14:59:46 +0200 Subject: [Nek5000-users] Tolerances In-Reply-To: <0D6667A2-88F9-4DAE-BAA9-BC9EC5F76852@lav.mavt.ethz.ch> References: <4BD7EE38.6060809@mech.kth.se> <0D6667A2-88F9-4DAE-BAA9-BC9EC5F76852@lav.mavt.ethz.ch> Message-ID: <4BD83142.6090903@mech.kth.se> Dear Stefan, Thank you for your quick reply! Yes, we have already tried to refine the computational domain by rising the polynomial order from 7 to 9 (lx1=8 -> 10) which does not improve the quality of the results much (numerical artefacts in the freestream are damped while the numerically excited crossflow waves remain unchanged). In the case of higher resolution one disturbance wavelength would be resolved by 37 points on average which sounds enough to us. We will try to further refine the domain and to "play" with the filtering at highest order. Maybe we can suppress the numerical noise triggering the physical instability in this way... Cheers, David Lars-Uve nek5000-users at lists.mcs.anl.gov wrote: > Do you really think 15 pressure iterations are too much? Considering you strict tolerance I would say it's pretty good! I am not sure what triggers your noise but did you try to use a high resolution? > > In your case TOLREL/TOLABS are not important! > > The tolerance you specify in DIVERGENCE is for the pressure solver. In fact if you use the PN/PN_2 scheme you'll end up with a divergence of the velocity which is comparable to DIVERGENCE. The pressure solve projects the velocity on a divergence free space. and you can control the divergence by varying the pressure tolerance (that's why we call it DIVERGENCE). In the PN/PN scheme things are different. > > The HELMHOLTZ controls the tolerance for all Helmholtz solves so if you don't have any passive scalars it's just for the velocity. > > Stefan > From nek5000-users at lists.mcs.anl.gov Wed Apr 28 08:56:38 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 28 Apr 2010 08:56:38 -0500 (CDT) Subject: [Nek5000-users] Tolerances In-Reply-To: <4BD83142.6090903@mech.kth.se> References: <4BD7EE38.6060809@mech.kth.se> <0D6667A2-88F9-4DAE-BAA9-BC9EC5F76852@lav.mavt.ethz.ch> <4BD83142.6090903@mech.kth.se> Message-ID: Just to give you some idea of the potential for looking at these stabilities, resolution reqmts, etc., you might look at: www.mcs.anl.gov/~fischer/users.pdf which scopes out several problems, including some stability ones. (Though I've yet to get the OS problem typed up and put in this ever-growing document...) Paul On Wed, 28 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Dear Stefan, > > Thank you for your quick reply! > > Yes, we have already tried to refine the computational domain by rising the > polynomial order from 7 to 9 (lx1=8 -> 10) which does not improve the quality > of the results much (numerical artefacts in the freestream are damped while > the numerically excited crossflow waves remain unchanged). > In the case of higher resolution one disturbance wavelength would be resolved > by 37 points on average which sounds enough to us. We will try to further > refine the domain and to "play" with the filtering at highest order. Maybe we > can suppress the numerical noise triggering the physical instability in this > way... > > Cheers, > > David > Lars-Uve > > > > nek5000-users at lists.mcs.anl.gov wrote: >> Do you really think 15 pressure iterations are too much? Considering you >> strict tolerance I would say it's pretty good! I am not sure what triggers >> your noise but did you try to use a high resolution? >> >> In your case TOLREL/TOLABS are not important! >> >> The tolerance you specify in DIVERGENCE is for the pressure solver. In fact >> if you use the PN/PN_2 scheme you'll end up with a divergence of the >> velocity which is comparable to DIVERGENCE. The pressure solve projects the >> velocity on a divergence free space. and you can control the divergence by >> varying the pressure tolerance (that's why we call it DIVERGENCE). In the >> PN/PN scheme things are different. >> >> The HELMHOLTZ controls the tolerance for all Helmholtz solves so if you >> don't have any passive scalars it's just for the velocity. >> >> Stefan >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Apr 29 07:44:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Apr 2010 14:44:21 +0200 Subject: [Nek5000-users] Example 'turbChannel' Emergency exit In-Reply-To: References: <4BC57C0C.4000800@kit.edu> <6C58009F-4C89-4922-99B7-064BE8066A1E@lav.mavt.ethz.ch> <4A7A3A5D-F34D-4FD8-A49E-B52D309649E9@lav.mavt.ethz.ch> Message-ID: <4BD97F25.5060008@gmail.com> Hello Nek's, Just a short email to say that I encounter the same problem when running the stenosis example. I deleted Nek5k and re-downloaded the last repo to be sure I did not messed up something in the files, but I ended up with the same error at the same time step (23). Regards, JC From nek5000-users at lists.mcs.anl.gov Thu Apr 29 09:57:41 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Apr 2010 09:57:41 -0500 (CDT) Subject: [Nek5000-users] Example 'turbChannel' Emergency exit In-Reply-To: <4BD97F25.5060008@gmail.com> References: <4BC57C0C.4000800@kit.edu> <6C58009F-4C89-4922-99B7-064BE8066A1E@lav.mavt.ethz.ch> <4A7A3A5D-F34D-4FD8-A49E-B52D309649E9@lav.mavt.ethz.ch> <4BD97F25.5060008@gmail.com> Message-ID: Hi All, Thanks for the feedback. In looking at the stenosis example, I see that I made no attempt to verify that this case was one that would actually run to completion. The example was really designed to illustrate a commonly used approach to mesh manipulation, under the assumption that users would subsequently choose a functional set of parameters of interest. I found that if I reduce dt by half the case goes through -- std approach to recovering stability. We'll rework this and the other examples to make certain that they are run-able, as opposed to simply providing guidance for implementation strategies. The slight downside will be that the essential elements of the example will become obscured in the .usr file, but we'll try to keep them as clear as possible. Regarding turbulent channel, I know we were looking at that a short while ago -- I'll check into the status. Paul On Thu, 29 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello Nek's, > > Just a short email to say that I encounter the same problem when running the > stenosis example. > I deleted Nek5k and re-downloaded the last repo to be sure I did not messed > up something in the files, but I ended up with the same error at the same > time step (23). > > Regards, > > JC > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Thu Apr 29 10:00:34 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Apr 2010 17:00:34 +0200 Subject: [Nek5000-users] define objects Message-ID: <4BD99F12.7050102@kit.edu> dear neks, is there an easy way to define objects? is there a possibility to do similar to the boundary conditions "set entire level"...? or do i have to add all faces by hand?? because i wanted to define my sphere as an "surface object" instead of using wall boundary conditions. cause i wanted to use the 'calc_drag' routine. and how i understood, this routines calculates the drag of objects, or?? best, fred From nek5000-users at lists.mcs.anl.gov Thu Apr 29 10:21:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Apr 2010 17:21:07 +0200 Subject: [Nek5000-users] makenek, sun complier & mpi In-Reply-To: References: <1271851086.31181.46.camel@localhost.localdomain> <788AC4AE-3A69-4423-BCB9-623BBC6622A0@lav.mavt.ethz.ch> Message-ID: <0685AAAB-9FFD-4071-814A-1FC075F4A17D@lav.mavt.ethz.ch> I have just fixed the SUN compiler problems in the latest release. Stefan On Apr 21, 2010, at 2:25 PM, nek5000-users at lists.mcs.anl.gov wrote: > Ok I think what happens is the following: > > We need to detect which compilers are used by the MPI-wrappers. Depending on the MPI implementation there are some flags (e.g. -showme / -show) you can use to figure that out. > > MPICH doesn't know the flag -showme hence it is passed to the compiler (in your case sunf95). > The sun compiler says this is an unknown flag and returns a ZERO exit code. > This is weird if not to say wrong because you would assume that the right exit code should be NON-ZERO in this case! > > It looks like only the SUN compiler behaves wrong in this situation. > Unfortunately I don't have access to machine with MPICH/SUN so I cannot test my hypothesis. > > Stefan > > > On Apr 21, 2010, at 2:00 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> What MPI implementation are you using? >> >> Stefan >> >> >> On Apr 21, 2010, at 1:58 PM, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello all, >>> >>> I am seeing the following error message when I use an mpif77 and mpicc >>> that use the Sun compilers. Everything is fine if in makenek F77=sunf95 >>> and CC=suncc (and IFMPI="false"), or if using mpif77 and mpicc that use >>> the Intel compilers. >>> >>> Cheers, >>> Frank >>> >>> >>> sunf95: Warning: Option -showme passed to ld, if ld is invoked, ignored >>> otherwise >>> Usage: sunf95 [ options ] files. Use 'sunf95 -flags' for details >>> WARNING: Cannot detect compiler specfic flags >>> echo - to promote REAL to 8 bytes >>> echo - to invoke preprocessor first >>> Please edit the makefile and specify the requested compiler flags in the >>> P variable! >>> >>> -- >>> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >>> Technische Universit?t Wien (Technical University of Vienna) >>> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >>> Mechanics and Heat Transfer) >>> Resselgasse 3 >>> 1040 Wien >>> Tel: +4315880132232 >>> Fax: +4315880132299 >>> Cell:+436765203470 >>> fmuldoo (skype) >>> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 29 15:01:58 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Apr 2010 22:01:58 +0200 Subject: [Nek5000-users] mesh precision Message-ID: <1272571318.3338.233.camel@localhost.localdomain> Hello all, >From the *.rea files I have seen (including in the examples), all numbers describing the mesh are single precision. I am wondering why that is the case; would not double precision values be better? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Apr 29 15:54:16 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 29 Apr 2010 15:54:16 -0500 (CDT) Subject: [Nek5000-users] mesh precision In-Reply-To: <1272571318.3338.233.camel@localhost.localdomain> References: <1272571318.3338.233.camel@localhost.localdomain> Message-ID: Hi Frank, For most engineering calculations, single precision is sufficient and the code was written w/ this in mind. That being said, for convergence studies and for stability simulations like yours, it can be of use to have higher precision. In fact, I'm wondering if that's the source of difficulty in your current high Reynolds number runs - but haven't had time yet to test this hypothesis. My std. approach is to project the input coordinates, xc(), yc(), and zc(), onto the cylinder in usrdat(), at which point they are then used to generate the geometry arrays, xm1, ym1, zm1. usrdat() was originally designed for precisely this type of application. hth, Paul On Thu, 29 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, >From the *.rea files I have seen (including in the examples), all numbers describing the mesh are single precision. I am wondering why that is the case; would not double precision values be better? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Apr 29 17:23:21 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 Apr 2010 00:23:21 +0200 Subject: [Nek5000-users] genmap, ABORT: SELF-CHK Message-ID: <1272579801.3338.242.camel@localhost.localdomain> Hello all, I am running into a problem with "genmap", see error below. My *.rea file that I feed to "genmap" is: http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim11/openboat3D.rea [root at frank sim11]# genmap Input (.rea) file name: openboat3D Input mesh tolerance (default 0.2): NOTE: smaller is better, but generous is more forgiving for bad meshes. .2 reading .rea file data ... start locglob_lexico: 8 1 8 0.200000000000000 locglob: 1 1 8 locglob: 2 2 8 locglob: 3 4 8 locglob: 1 8 8 locglob: 2 8 8 locglob: 3 8 8 locglob: 1 8 8 locglob: 2 8 8 locglob: 3 8 8 done locglob_lexico: 8 8 8 1 start periodic vtx: 1 8 1 5 5 3 0.00000000E+00 1 shift 1 6 5 3 0.00000000E+00 2 shift 1 2 4 Matrix: SELF!! 1 SELF!! 1 2 1 2 2 SELF!! 3 4 3 4 ABORT: SELF-CHK 1 5 1 6 Try to tighten the mesh tolerance! 6 quit Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Thu Apr 29 17:32:18 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 Apr 2010 00:32:18 +0200 Subject: [Nek5000-users] mesh precision In-Reply-To: References: <1272571318.3338.233.camel@localhost.localdomain> Message-ID: <1272580338.3338.252.camel@localhost.localdomain> Hi Paul, I doubt that the input precision of the mesh could be causing this problem. The instability is not at all a weak one. As an unrelated aside, the Intel and Sun compilers can generate quad precision code. I use this quite often when computing derivatives of objective functions wrt a discrete velocity. Cheers, Frank On Thu, 2010-04-29 at 15:54 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Frank, > > For most engineering calculations, single precision is > sufficient and the code was written w/ this in mind. > > That being said, for convergence studies and for stability > simulations like yours, it can be of use to have higher > precision. > > In fact, I'm wondering if that's the source of difficulty > in your current high Reynolds number runs - but haven't > had time yet to test this hypothesis. My std. approach > is to project the input coordinates, xc(), yc(), and zc(), > onto the cylinder in usrdat(), at which point they are > then used to generate the geometry arrays, xm1, ym1, zm1. > > usrdat() was originally designed for precisely this type > of application. > > hth, > > Paul > > > On Thu, 29 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > > > Hello all, > > >From the *.rea files I have seen (including in the examples), all > numbers describing the mesh are single precision. I am wondering why > that is the case; would not double precision values be better? > > Cheers, > Frank > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit?t Wien (Technical University of Vienna) > Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html From nek5000-users at lists.mcs.anl.gov Fri Apr 30 07:16:50 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 Apr 2010 07:16:50 -0500 Subject: [Nek5000-users] Restarting simulation from instantenous & average velocity field files Message-ID: Hello Paul & Stefan, I am running a DNS simulation of backward facing simulation (BFS) at Re=3000. The Reynolds # is based on step height (h=1) & free stream velocity (ux = 1.0). The BFS geometry has 5184 elements and lx1=ly1=lz1=8. After running for about 10 flow throughs, we started computing averages. I want to restart simulation after 2 flow throughs, but I have 2 field files one for instantaneous (blah.fld01) and the other for average (avgblah.fld01). To continue computing averages I need to read in both the velocity field files. Is there an option to restart from 2 field files? Or how else can I do this? I will also require this option later for computing "rms" velocities. Thanks, Harish. From nek5000-users at lists.mcs.anl.gov Fri Apr 30 07:37:07 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 Apr 2010 14:37:07 +0200 Subject: [Nek5000-users] Restarting simulation from instantenous & average velocity field files In-Reply-To: References: Message-ID: Harish, you can compute mean and variances based on the averages we computed in avg_all(). The averages E(X), E(X*X), E(X*Y) are stored in the common blocks defined in AVG (make sure you set lxa in SIZE correct). The averages are dumped into different files (I/O freq can be adjusted with param(68): *.avg -- E(X) *.rms -- E(X*X) *.rm2 -- E(X*Y) If you have want to compute the mean and variance of multiple files, run Nek in postprocessing mode and read the *.avg files and the *.rms files using load_fld() and sum up the averages for every variable (you need some temporary arrays for that). Then compute the variance as var(X) := E(X^X) - E(X)*E(X) Finally just dump the final arrays containing your mean and/or variances. hth, Stefan On Apr 30, 2010, at 2:16 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hello Paul & Stefan, > > I am running a DNS simulation of backward facing simulation (BFS) at > Re=3000. The Reynolds # is based on step height (h=1) & free stream > velocity (ux = 1.0). The BFS geometry has 5184 elements and lx1=ly1=lz1=8. > > After running for about 10 flow throughs, we started computing averages. I > want to restart simulation after 2 flow throughs, but I have 2 field files > one for instantaneous (blah.fld01) and the other for average > (avgblah.fld01). To continue computing averages I need to read in both the > velocity field files. Is there an option to restart from 2 field files? Or > how else can I do this? I will also require this option later for > computing "rms" velocities. > > Thanks, > > Harish. > > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Apr 30 07:37:59 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 Apr 2010 07:37:59 -0500 (CDT) Subject: [Nek5000-users] Restarting simulation from instantenous & average velocity field files In-Reply-To: References: Message-ID: Hi Harish, 2 PRESOLVE/RESTART OPTIONS ***** blah.fld01 X blah.fld02 U P will take geometry (say) from .fld01 and velocity/pressure from fld02, as well as time from the last file listed. In your case, why not just restart, and then subsequently average your avg files ? We have some small codes for doing this. Paul On Fri, 30 Apr 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello Paul & Stefan, > > I am running a DNS simulation of backward facing simulation (BFS) at > Re=3000. The Reynolds # is based on step height (h=1) & free stream > velocity (ux = 1.0). The BFS geometry has 5184 elements and lx1=ly1=lz1=8. > > After running for about 10 flow throughs, we started computing averages. I > want to restart simulation after 2 flow throughs, but I have 2 field files > one for instantaneous (blah.fld01) and the other for average > (avgblah.fld01). To continue computing averages I need to read in both the > velocity field files. Is there an option to restart from 2 field files? Or > how else can I do this? I will also require this option later for > computing "rms" velocities. > > Thanks, > > Harish. > > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri Apr 30 19:45:44 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 01 May 2010 02:45:44 +0200 Subject: [Nek5000-users] Periodic BC Message-ID: <1272674744.18612.76.camel@localhost.localdomain> Hello all, I have a real simple mesh, one element. Running genmap with periodic BC's fails. Replace the periodic BC's with walls and then genmap works. Anybody have any ideas? Cheers, Frank ELEMENT 1 [ 1a] GROUP 0 -0.400000E+01 0.400000E+01 0.400000E+01 -0.400000E+01 -0.500000E+00 -0.500000E+00 0.500000E+00 0.500000E+00 -0.500000E+00 -0.500000E+00 -0.500000E+00 -0.500000E+00 -0.400000E+01 0.400000E+01 0.400000E+01 -0.400000E+01 -0.500000E+00 -0.500000E+00 0.500000E+00 0.500000E+00 0.500000E+00 0.500000E+00 0.500000E+00 0.500000E+00 ***** CURVED SIDE DATA ***** 0 Curved sides follow IEDGE,IEL,CURVE(I),I=1,5, CCURVE ***** BOUNDARY CONDITIONS ***** ***** FLUID BOUNDARY CONDITIONS ***** W 1 1 0.000000 0.000000 0.000000 0.000000 0.000000 W 1 2 0.000000 0.000000 0.000000 0.000000 0.000000 shl 1 3 0.000000 0.000000 0.000000 0.000000 0.000000 W 1 4 0.000000 0.000000 0.000000 0.000000 0.000000 P 1 5 1.000000 6.000000 0.000000 0.000000 0.000000 P 1 6 1.000000 5.000000 0.000000 0.000000 0.000000 ***** THERMAL BOUNDARY CONDITIONS ***** 1 1 0.000000 0.000000 0.000000 0.000000 0.000000 t 1 2 0.000000 0.000000 0.000000 0.000000 0.000000 1 3 0.000000 0.000000 0.000000 0.000000 0.000000 t 1 4 0.000000 0.000000 0.000000 0.000000 0.000000 P 1 5 1.000000 6.000000 0.000000 0.000000 0.000000 P 1 6 1.000000 5.000000 0.000000 0.000000 0.000000 -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universit?t Wien (Technical University of Vienna) Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Apr 30 20:27:55 2010 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 30 Apr 2010 20:27:55 -0500 (CDT) Subject: [Nek5000-users] Periodic BC In-Reply-To: <1272674744.18612.76.camel@localhost.localdomain> References: <1272674744.18612.76.camel@localhost.localdomain> Message-ID: Hi Frank, Yes -- we currently don't support periodic bcs for anything smaller than a 3 x 3 x 3 array of elements. There's a technical reason for this --- it can be circumvented if really needed, but it would not fit within the std. context. Sorry about that. Paul PS - the technical reason has to do with the fact that a 2 element mesh, periodic in x, would have global vertices numbered 1-----2-----1 along one of the edges of the domain. Nek would not be able to understand that the 1-2 edge is not shared with the 2-1 edge... On Sat, 1 May 2010, nek5000-users at lists.mcs.anl.gov wrote: > Hello all, > > I have a real simple mesh, one element. Running genmap with periodic > BC's fails. Replace the periodic BC's with walls and then genmap works. > Anybody have any ideas? > > Cheers, > Frank > > ELEMENT 1 [ 1a] GROUP 0 > -0.400000E+01 0.400000E+01 0.400000E+01 -0.400000E+01 > -0.500000E+00 -0.500000E+00 0.500000E+00 0.500000E+00 > -0.500000E+00 -0.500000E+00 -0.500000E+00 -0.500000E+00 > -0.400000E+01 0.400000E+01 0.400000E+01 -0.400000E+01 > -0.500000E+00 -0.500000E+00 0.500000E+00 0.500000E+00 > 0.500000E+00 0.500000E+00 0.500000E+00 0.500000E+00 > ***** CURVED SIDE DATA ***** > 0 Curved sides follow IEDGE,IEL,CURVE(I),I=1,5, CCURVE > ***** BOUNDARY CONDITIONS ***** > ***** FLUID BOUNDARY CONDITIONS ***** > W 1 1 0.000000 0.000000 0.000000 0.000000 > 0.000000 > W 1 2 0.000000 0.000000 0.000000 0.000000 > 0.000000 > shl 1 3 0.000000 0.000000 0.000000 0.000000 > 0.000000 > W 1 4 0.000000 0.000000 0.000000 0.000000 > 0.000000 > P 1 5 1.000000 6.000000 0.000000 0.000000 > 0.000000 > P 1 6 1.000000 5.000000 0.000000 0.000000 > 0.000000 > ***** THERMAL BOUNDARY CONDITIONS ***** > 1 1 0.000000 0.000000 0.000000 0.000000 > 0.000000 > t 1 2 0.000000 0.000000 0.000000 0.000000 > 0.000000 > 1 3 0.000000 0.000000 0.000000 0.000000 > 0.000000 > t 1 4 0.000000 0.000000 0.000000 0.000000 > 0.000000 > P 1 5 1.000000 6.000000 0.000000 0.000000 > 0.000000 > P 1 6 1.000000 5.000000 0.000000 0.000000 > 0.000000 > > > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > Technische Universit??t Wien (Technical University of Vienna) > Inst. f. Str??mungsmechanik und W??rme??bertragung (Institute of Fluid > Mechanics and Heat Transfer) > Resselgasse 3 > 1040 Wien > Tel: +4315880132232 > Fax: +4315880132299 > Cell:+436765203470 > fmuldoo (skype) > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html >