From nek5000-users at lists.mcs.anl.gov Wed Feb 1 03:06:40 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 01 Feb 2012 10:06:40 +0100 Subject: [Nek5000-users] Nek5000-users Digest, Vol 35, Issue 21 In-Reply-To: References: Message-ID: <4F2900A0.70601@iag.uni-stuttgart.de> Dear Stefan and Paul, Thank you for your replies. The code compiles nicely and the same case runs when I compile with PGI (for some reason that wasn't the case with the older Nek version I used before; it compiled but gave segmentation faults before creating any other output). Cray people told me however that I should use crayftn for better performance, at least for large cases. Any thoughts? Oliver > Send Nek5000-users mailing list submissions to > nek5000-users at lists.mcs.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > or, via email, send a message with subject or body 'help' to > nek5000-users-request at lists.mcs.anl.gov > > You can reach the person managing the list at > nek5000-users-owner at lists.mcs.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nek5000-users digest..." > > > Today's Topics: > > 1. Re: Running NEK on CRAY; compilation& running issues > (nek5000-users at lists.mcs.anl.gov) > 2. Re: Running NEK on CRAY; compilation& running issues > (nek5000-users at lists.mcs.anl.gov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Jan 2012 19:02:23 +0100 > From: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Running NEK on CRAY; compilation& > running issues > To: nek5000-users at lists.mcs.anl.gov > Message-ID: > > Content-Type: text/plain; charset=windows-1252 > > Hi Oliver, > > Can you try to use the PGI compiler instead of the Cray. Just want to > check if this is a compiler specific issue. > > Cheers, > Stefan > > On 1/30/12, nek5000-users at lists.mcs.anl.gov > wrote: >> Oliver, >> >> Thanks for your comments. We'll certainly take care of the >> multd() and gsync() issues. >> >> We have what I believe is an xe6 on site and several users >> are using it regularly. They may have some comments about >> the flags, etc. and the issues that you are running into. >> Hopefully, someone will get back to you early today. >> >> Regards, >> >> Paul >> >> >> On Mon, 30 Jan 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear NEKs, >>> >>> I'm currently trying to compile NEK via crayftn to run on a XE6 and I >>> run into some issues. Some compilation problems I solved (with kind help >>> of CRAY personnel). I'll mention them here as they can be part of the >>> problem, I assume. >>> >>> 1) changed >>> *ftn*) P="-r8 -Mpreprocess >>> to *ftn*) P="-s real64 -eZ -em" >>> for double precision reals and to invoke preprocessor in makenek.inc >>> (Cray uses ftn command as a wrapper) >>> >>> 2) changed subroutine name ?gsync? to ?gsync_nek? in all source files >>> as >>> crayftn has a build-in routine of the same name that conflicts with >>> Nek's gsync >>> >>> 3) changed calls to subroutine ?multd? from >>> CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1) >>> to CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1,0) >>> in ?navier1.f? as crayftn complains about missing seventh argument >>> ?iflg? (calls come from subroutine ?tmultd? which seems not to be >>> called >>> in the code, though) >>> >>> In the SIZE file I'm setting lelt=300, lelv=lelt, lp = 64, lelg = 300. >>> With these changes I'm running the eddy_uv example via ?aprun -n 64 -N >>> 32 ./nek5000? on 64 processors and I'm getting the following output: >>> >>> /----------------------------------------------------------\\ >>> | _ __ ______ __ __ ______ ____ ____ ____ | >>> | / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\ | >>> | / |/ // __/ / ,< /___ \\ / / / // / / // / / / | >>> | / /| // /___ / /| | ____/ / / /_/ // /_/ // /_/ / | >>> | /_/ |_//_____//_/ |_|/_____/ \\____/ \\____/ \\____/ | >>> | | >>> |----------------------------------------------------------| >>> | | >>> | NEK5000: Open Source Spectral Element Solver | >>> | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC | >>> | Version: 1.0rc1 / SVN r730 | >>> | Web: http://nek5000.mcs.anl.gov | >>> | | >>> \\----------------------------------------------------------/ >>> >>> >>> Number of processors: 64 >>> REAL wdsize : 8 >>> INTEGER wdsize : 4 >>> >>> >>> Beginning session: >>> /zhome/academic/HLRS/iag/iagoschm/run_nek/eddy_example/eddy_uv.rea >>> >>> >>> timer accuracy: 2.8610229E-07 sec >>> >>> read .rea file >>> nelgt/nelgv/lelt: 256 256 300 >>> lx1 /lx2 /lx3 : 8 6 8 >>> >>> mapping elements to processors >>> 0, 2*4, 2*256 NELV >>> 1, 2*4, 2*256 NELV >>> 8, 2*4, 2*256 NELV >>> 9, 2*4, 2*256 NELV >>> 17, 2*4, 2*256 NELV >>> 16, 2*4, 2*256 NELV >>> 20, 2*4, 2*256 NELV >>> 3*4, 2*256 NELV >>> 29, 2*4, 2*256 NELV >>> 21, 2*4, 2*256 NELV >>> 28, 2*4, 2*256 NELV >>> 7, 2*4, 2*256 NELV >>> 31, 2*4, 2*256 NELV >>> 25, 2*4, 2*256 NELV >>> 11, 2*4, 2*256 NELV >>> 12, 2*4, 2*256 NELV >>> 6, 2*4, 2*256 NELV >>> 30, 2*4, 2*256 NELV >>> 18, 2*4, 2*256 NELV >>> 19, 2*4, 2*256 NELV >>> 2, 2*4, 2*256 NELV >>> 5, 2*4, 2*256 NELV >>> 23, 2*4, 2*256 NELV >>> 27, 2*4, 2*256 NELV >>> 10, 2*4, 2*256 NELV >>> 22, 2*4, 2*256 NELV >>> 13, 2*4, 2*256 NELV >>> 14, 2*4, 2*256 NELV >>> 15, 2*4, 2*256 NELV >>> 3, 2*4, 2*256 NELV >>> 26, 2*4, 2*256 NELV >>> 24, 2*4, 2*256 NELV >>> 33, 2*4, 2*256 NELV >>> 41, 2*4, 2*256 NELV >>> 32, 2*4, 2*256 NELV >>> 40, 2*4, 2*256 NELV >>> 45, 2*4, 2*256 NELV >>> 44, 2*4, 2*256 NELV >>> 49, 2*4, 2*256 NELV >>> 34, 2*4, 2*256 NELV >>> 35, 2*4, 2*256 NELV >>> 48, 2*4, 2*256 NELV >>> 39, 2*4, 2*256 NELV >>> 38, 2*4, 2*256 NELV >>> 50, 2*4, 2*256 NELV >>> 51, 2*4, 2*256 NELV >>> 37, 2*4, 2*256 NELV >>> 36, 2*4, 2*256 NELV >>> 55, 2*4, 2*256 NELV >>> 54, 2*4, 2*256 NELV >>> 57, 2*4, 2*256 NELV >>> 58, 2*4, 2*256 NELV >>> 43, 2*4, 2*256 NELV >>> 42, 2*4, 2*256 NELV >>> 47, 2*4, 2*256 NELV >>> 53, 2*4, 2*256 NELV >>> 59, 2*4, 2*256 NELV >>> 46, 2*4, 2*256 NELV >>> 60, 2*4, 2*256 NELV >>> 61, 2*4, 2*256 NELV >>> 63, 2*4, 2*256 NELV >>> 62, 2*4, 2*256 NELV >>> 52, 2*4, 2*256 NELV >>> 56, 2*4, 2*256 NELV >>> 25, 0, 2*4, 256 NELT FAIL >>> 24, 0, 2*4, 256 NELT FAIL >>> 21, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 20, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 31, 0, 2*4, 256 NELT FAIL >>> 8, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 17, 0, 2*4, 256 NELT FAIL >>> 14, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 15, 0, 2*4, 256 NELT FAIL >>> 16, 0, 2*4, 256 NELT FAIL >>> 26, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 10, 0, 2*4, 256 NELT FAIL >>> 2, 0, 2*4, 256 NELT FAIL >>> 30, 0, 2*4, 256 NELT FAIL >>> 11, 0, 2*4, 256 NELT FAIL >>> 7, 0, 2*4, 256 NELT FAIL >>> 1, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 2*0, 2*4, 256 NELT FAIL >>> 6, 0, 2*4, 256 NELT FAIL >>> 4, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 13, 0, 2*4, 256 NELT FAIL >>> 12, 0, 2*4, 256 NELT FAIL >>> 28, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 18, 0, 2*4, 256 NELT FAIL >>> 29, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 23, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 27, 0, 2*4, 256 NELT FAIL >>> 3, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 19, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 5, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 22, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 2*0, 2*4, 256 NELT FB >>> 1, 0, 2*4, 256 NELT FB >>> 2, 0, 2*4, 256 NELT FB >>> 3, 0, 2*4, 256 NELT FB >>> 4, 0, 2*4, 256 NELT FB >>> 5, 0, 2*4, 256 NELT FB >>> 6, 0, 2*4, 256 NELT FB >>> 7, 0, 2*4, 256 NELT FB >>> 8, 0, 2*4, 256 NELT FB >>> 9, 3*4, 256 NELT FB >>> 10, 0, 2*4, 256 NELT FB >>> 11, 0, 2*4, 256 NELT FB >>> 12, 0, 2*4, 256 NELT FB >>> 13, 0, 2*4, 256 NELT FB >>> 14, 0, 2*4, 256 NELT FB >>> 15, 0, 2*4, 256 NELT FB >>> 16, 0, 2*4, 256 NELT FB >>> 17, 0, 2*4, 256 NELT FB >>> 18, 0, 2*4, 256 NELT FB >>> 19, 0, 2*4, 256 NELT FB >>> 20, 0, 2*4, 256 NELT FB >>> 21, 0, 2*4, 256 NELT FB >>> 22, 0, 2*4, 256 NELT FB >>> 23, 0, 2*4, 256 NELT FB >>> 24, 0, 2*4, 256 NELT FB >>> 25, 0, 2*4, 256 NELT FB >>> 26, 0, 2*4, 256 NELT FB >>> 27, 0, 2*4, 256 NELT FB >>> 28, 0, 2*4, 256 NELT FB >>> 29, 0, 2*4, 256 NELT FB >>> 30, 0, 2*4, 256 NELT FB >>> 31, 0, 2*4, 256 NELT FB >>> >>> call exitt: dying ... >>> >>> backtrace(): obtained 1 stack frames. >>> [0x662a40] >>> >>> total elapsed time : 7.82199E-02 sec >>> total solver time incl. I/O : 0.00000E+00 sec >>> time/timestep : 0.00000E+00 sec >>> CPU seconds/timestep/gridpt : 0.00000E+00 sec >>> >>> 39, 0, 2*4, 256 NELT FAIL >>> 38, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 36, 0, 2*4, 256 NELT FAIL >>> 41, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 32, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 48, 0, 2*4, 256 NELT FAIL >>> 34, 0, 2*4, 256 NELT FAIL >>> 54, 196, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 40, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 46, 0, 2*4, 256 NELT FAIL >>> 47, 0, 2*4, 256 NELT FAIL >>> 33, 0, 2*4, 256 NELT FAIL >>> 37, 0, 2*4, 256 NELT FAIL >>> 35, 0, 2*4, 256 NELT FAIL >>> 43, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 45, 0, 2*4, 256 NELT FAIL >>> 42, 0, 2*4, 256 NELT FAIL >>> 44, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 32, 0, 2*4, 256 NELT FB >>> 33, 0, 2*4, 256 NELT FB >>> 34, 0, 2*4, 256 NELT FB >>> 35, 0, 2*4, 256 NELT FB >>> 36, 0, 2*4, 256 NELT FB >>> 37, 0, 2*4, 256 NELT FB >>> 38, 0, 2*4, 256 NELT FB >>> 39, 0, 2*4, 256 NELT FB >>> 40, 0, 2*4, 256 NELT FB >>> 41, 0, 2*4, 256 NELT FB >>> 42, 0, 2*4, 256 NELT FB >>> 43, 0, 2*4, 256 NELT FB >>> 44, 0, 2*4, 256 NELT FB >>> 45, 0, 2*4, 256 NELT FB >>> 46, 0, 2*4, 256 NELT FB >>> 47, 0, 2*4, 256 NELT FB >>> 48, 0, 2*4, 256 NELT FB >>> 49, 3*4, 256 NELT FB >>> 50, 3*4, 256 NELT FB >>> 51, 3*4, 256 NELT FB >>> 52, 3*4, 256 NELT FB >>> 53, 3*4, 256 NELT FB >>> 54, 196, 2*4, 256 NELT FB >>> 55, 3*4, 256 NELT FB >>> 56, 3*4, 256 NELT FB >>> 57, 3*4, 256 NELT FB >>> 58, 3*4, 256 NELT FB >>> 59, 3*4, 256 NELT FB >>> 60, 3*4, 256 NELT FB >>> 61, 3*4, 256 NELT FB >>> 62, 3*4, 256 NELT FB >>> 63, 3*4, 256 NELT FB >>> Application 419539 resources: utime ~8s, stime ~13s >>> >>> Does the code map in parallel here? I'm not sure what's happening here, >>> because the .map and .rea file do in fact agree. The error seems to >>> occur when processor #25 is mapped for a second time. The same thing >>> happens with my own cases that were running on a similar machine before >>> but with Nek compiled with PGI. >>> >>> Any help would be greatly appreciated >>> >>> Oliver >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> > > ------------------------------ > > Message: 2 > Date: Mon, 30 Jan 2012 13:43:50 -0600 (CST) > From: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Running NEK on CRAY; compilation& > running issues > To: nek5000-users at lists.mcs.anl.gov > Message-ID: > <304748520.192593.1327952630495.JavaMail.root at zimbra.anl.gov> > Content-Type: text/plain; charset=utf-8 > > Hi Oliver, > > I have been using Cray xe6/xt6 successfully with PGI compilers specified in makenek with > > # Fortran compiler > F77="ftn" > > # C compiler > CC="cc" > > and the submission script I use is below. > > Best. > Aleks > > > rm *batch* > echo $1> SESSION.NAME > echo `pwd`'/'>> SESSION.NAME > touch $1.rea > rm -f ioinfo > mv -f $1.log.$2 $1.log1.$2 > mv -f $1.his $1.his1 > mv -f $1.sch $1.sch1 > rm -f logfile > echo ''> $1.log.$2 > echo "#!/bin/bash"> $1.batch > echo "#PBS -l mppwidth="$2>> $1.batch > echo "#PBS -l walltime="$3":"$4":00">> $1.batch > echo "#PBS -j oe">> $1.batch > echo cd `pwd`>> $1.batch > echo aprun -n $2 ./nek5000 ">>" $1.log.$2>> $1.batch > echo "exit 0;">> $1.batch > qsub -q batch $1.batch > sleep 3 > ln $1.log.$2 logfile > ## > ## usage: neke case cores hours minutes > > > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, January 30, 2012 12:02:23 PM > Subject: Re: [Nek5000-users] Running NEK on CRAY; compilation& running issues > > Hi Oliver, > > Can you try to use the PGI compiler instead of the Cray. Just want to > check if this is a compiler specific issue. > > Cheers, > Stefan > > On 1/30/12, nek5000-users at lists.mcs.anl.gov > wrote: >> Oliver, >> >> Thanks for your comments. We'll certainly take care of the >> multd() and gsync() issues. >> >> We have what I believe is an xe6 on site and several users >> are using it regularly. They may have some comments about >> the flags, etc. and the issues that you are running into. >> Hopefully, someone will get back to you early today. >> >> Regards, >> >> Paul >> >> >> On Mon, 30 Jan 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear NEKs, >>> >>> I'm currently trying to compile NEK via crayftn to run on a XE6 and I >>> run into some issues. Some compilation problems I solved (with kind help >>> of CRAY personnel). I'll mention them here as they can be part of the >>> problem, I assume. >>> >>> 1) changed >>> *ftn*) P="-r8 -Mpreprocess >>> to *ftn*) P="-s real64 -eZ -em" >>> for double precision reals and to invoke preprocessor in makenek.inc >>> (Cray uses ftn command as a wrapper) >>> >>> 2) changed subroutine name ?gsync? to ?gsync_nek? in all source files >>> as >>> crayftn has a build-in routine of the same name that conflicts with >>> Nek's gsync >>> >>> 3) changed calls to subroutine ?multd? from >>> CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1) >>> to CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1,0) >>> in ?navier1.f? as crayftn complains about missing seventh argument >>> ?iflg? (calls come from subroutine ?tmultd? which seems not to be >>> called >>> in the code, though) >>> >>> In the SIZE file I'm setting lelt=300, lelv=lelt, lp = 64, lelg = 300. >>> With these changes I'm running the eddy_uv example via ?aprun -n 64 -N >>> 32 ./nek5000? on 64 processors and I'm getting the following output: >>> >>> /----------------------------------------------------------\\ >>> | _ __ ______ __ __ ______ ____ ____ ____ | >>> | / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\ | >>> | / |/ // __/ / ,< /___ \\ / / / // / / // / / / | >>> | / /| // /___ / /| | ____/ / / /_/ // /_/ // /_/ / | >>> | /_/ |_//_____//_/ |_|/_____/ \\____/ \\____/ \\____/ | >>> | | >>> |----------------------------------------------------------| >>> | | >>> | NEK5000: Open Source Spectral Element Solver | >>> | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC | >>> | Version: 1.0rc1 / SVN r730 | >>> | Web: http://nek5000.mcs.anl.gov | >>> | | >>> \\----------------------------------------------------------/ >>> >>> >>> Number of processors: 64 >>> REAL wdsize : 8 >>> INTEGER wdsize : 4 >>> >>> >>> Beginning session: >>> /zhome/academic/HLRS/iag/iagoschm/run_nek/eddy_example/eddy_uv.rea >>> >>> >>> timer accuracy: 2.8610229E-07 sec >>> >>> read .rea file >>> nelgt/nelgv/lelt: 256 256 300 >>> lx1 /lx2 /lx3 : 8 6 8 >>> >>> mapping elements to processors >>> 0, 2*4, 2*256 NELV >>> 1, 2*4, 2*256 NELV >>> 8, 2*4, 2*256 NELV >>> 9, 2*4, 2*256 NELV >>> 17, 2*4, 2*256 NELV >>> 16, 2*4, 2*256 NELV >>> 20, 2*4, 2*256 NELV >>> 3*4, 2*256 NELV >>> 29, 2*4, 2*256 NELV >>> 21, 2*4, 2*256 NELV >>> 28, 2*4, 2*256 NELV >>> 7, 2*4, 2*256 NELV >>> 31, 2*4, 2*256 NELV >>> 25, 2*4, 2*256 NELV >>> 11, 2*4, 2*256 NELV >>> 12, 2*4, 2*256 NELV >>> 6, 2*4, 2*256 NELV >>> 30, 2*4, 2*256 NELV >>> 18, 2*4, 2*256 NELV >>> 19, 2*4, 2*256 NELV >>> 2, 2*4, 2*256 NELV >>> 5, 2*4, 2*256 NELV >>> 23, 2*4, 2*256 NELV >>> 27, 2*4, 2*256 NELV >>> 10, 2*4, 2*256 NELV >>> 22, 2*4, 2*256 NELV >>> 13, 2*4, 2*256 NELV >>> 14, 2*4, 2*256 NELV >>> 15, 2*4, 2*256 NELV >>> 3, 2*4, 2*256 NELV >>> 26, 2*4, 2*256 NELV >>> 24, 2*4, 2*256 NELV >>> 33, 2*4, 2*256 NELV >>> 41, 2*4, 2*256 NELV >>> 32, 2*4, 2*256 NELV >>> 40, 2*4, 2*256 NELV >>> 45, 2*4, 2*256 NELV >>> 44, 2*4, 2*256 NELV >>> 49, 2*4, 2*256 NELV >>> 34, 2*4, 2*256 NELV >>> 35, 2*4, 2*256 NELV >>> 48, 2*4, 2*256 NELV >>> 39, 2*4, 2*256 NELV >>> 38, 2*4, 2*256 NELV >>> 50, 2*4, 2*256 NELV >>> 51, 2*4, 2*256 NELV >>> 37, 2*4, 2*256 NELV >>> 36, 2*4, 2*256 NELV >>> 55, 2*4, 2*256 NELV >>> 54, 2*4, 2*256 NELV >>> 57, 2*4, 2*256 NELV >>> 58, 2*4, 2*256 NELV >>> 43, 2*4, 2*256 NELV >>> 42, 2*4, 2*256 NELV >>> 47, 2*4, 2*256 NELV >>> 53, 2*4, 2*256 NELV >>> 59, 2*4, 2*256 NELV >>> 46, 2*4, 2*256 NELV >>> 60, 2*4, 2*256 NELV >>> 61, 2*4, 2*256 NELV >>> 63, 2*4, 2*256 NELV >>> 62, 2*4, 2*256 NELV >>> 52, 2*4, 2*256 NELV >>> 56, 2*4, 2*256 NELV >>> 25, 0, 2*4, 256 NELT FAIL >>> 24, 0, 2*4, 256 NELT FAIL >>> 21, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 20, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 31, 0, 2*4, 256 NELT FAIL >>> 8, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 17, 0, 2*4, 256 NELT FAIL >>> 14, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 15, 0, 2*4, 256 NELT FAIL >>> 16, 0, 2*4, 256 NELT FAIL >>> 26, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 10, 0, 2*4, 256 NELT FAIL >>> 2, 0, 2*4, 256 NELT FAIL >>> 30, 0, 2*4, 256 NELT FAIL >>> 11, 0, 2*4, 256 NELT FAIL >>> 7, 0, 2*4, 256 NELT FAIL >>> 1, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 2*0, 2*4, 256 NELT FAIL >>> 6, 0, 2*4, 256 NELT FAIL >>> 4, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 13, 0, 2*4, 256 NELT FAIL >>> 12, 0, 2*4, 256 NELT FAIL >>> 28, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 18, 0, 2*4, 256 NELT FAIL >>> 29, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 23, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 27, 0, 2*4, 256 NELT FAIL >>> 3, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 19, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 5, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 22, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 2*0, 2*4, 256 NELT FB >>> 1, 0, 2*4, 256 NELT FB >>> 2, 0, 2*4, 256 NELT FB >>> 3, 0, 2*4, 256 NELT FB >>> 4, 0, 2*4, 256 NELT FB >>> 5, 0, 2*4, 256 NELT FB >>> 6, 0, 2*4, 256 NELT FB >>> 7, 0, 2*4, 256 NELT FB >>> 8, 0, 2*4, 256 NELT FB >>> 9, 3*4, 256 NELT FB >>> 10, 0, 2*4, 256 NELT FB >>> 11, 0, 2*4, 256 NELT FB >>> 12, 0, 2*4, 256 NELT FB >>> 13, 0, 2*4, 256 NELT FB >>> 14, 0, 2*4, 256 NELT FB >>> 15, 0, 2*4, 256 NELT FB >>> 16, 0, 2*4, 256 NELT FB >>> 17, 0, 2*4, 256 NELT FB >>> 18, 0, 2*4, 256 NELT FB >>> 19, 0, 2*4, 256 NELT FB >>> 20, 0, 2*4, 256 NELT FB >>> 21, 0, 2*4, 256 NELT FB >>> 22, 0, 2*4, 256 NELT FB >>> 23, 0, 2*4, 256 NELT FB >>> 24, 0, 2*4, 256 NELT FB >>> 25, 0, 2*4, 256 NELT FB >>> 26, 0, 2*4, 256 NELT FB >>> 27, 0, 2*4, 256 NELT FB >>> 28, 0, 2*4, 256 NELT FB >>> 29, 0, 2*4, 256 NELT FB >>> 30, 0, 2*4, 256 NELT FB >>> 31, 0, 2*4, 256 NELT FB >>> >>> call exitt: dying ... >>> >>> backtrace(): obtained 1 stack frames. >>> [0x662a40] >>> >>> total elapsed time : 7.82199E-02 sec >>> total solver time incl. I/O : 0.00000E+00 sec >>> time/timestep : 0.00000E+00 sec >>> CPU seconds/timestep/gridpt : 0.00000E+00 sec >>> >>> 39, 0, 2*4, 256 NELT FAIL >>> 38, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 36, 0, 2*4, 256 NELT FAIL >>> 41, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 32, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 48, 0, 2*4, 256 NELT FAIL >>> 34, 0, 2*4, 256 NELT FAIL >>> 54, 196, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> 40, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 46, 0, 2*4, 256 NELT FAIL >>> 47, 0, 2*4, 256 NELT FAIL >>> 33, 0, 2*4, 256 NELT FAIL >>> 37, 0, 2*4, 256 NELT FAIL >>> 35, 0, 2*4, 256 NELT FAIL >>> 43, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 45, 0, 2*4, 256 NELT FAIL >>> 42, 0, 2*4, 256 NELT FAIL >>> 44, 0, 2*4, 256 NELT FAIL >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> Check that .map file and .rea file agree >>> 32, 0, 2*4, 256 NELT FB >>> 33, 0, 2*4, 256 NELT FB >>> 34, 0, 2*4, 256 NELT FB >>> 35, 0, 2*4, 256 NELT FB >>> 36, 0, 2*4, 256 NELT FB >>> 37, 0, 2*4, 256 NELT FB >>> 38, 0, 2*4, 256 NELT FB >>> 39, 0, 2*4, 256 NELT FB >>> 40, 0, 2*4, 256 NELT FB >>> 41, 0, 2*4, 256 NELT FB >>> 42, 0, 2*4, 256 NELT FB >>> 43, 0, 2*4, 256 NELT FB >>> 44, 0, 2*4, 256 NELT FB >>> 45, 0, 2*4, 256 NELT FB >>> 46, 0, 2*4, 256 NELT FB >>> 47, 0, 2*4, 256 NELT FB >>> 48, 0, 2*4, 256 NELT FB >>> 49, 3*4, 256 NELT FB >>> 50, 3*4, 256 NELT FB >>> 51, 3*4, 256 NELT FB >>> 52, 3*4, 256 NELT FB >>> 53, 3*4, 256 NELT FB >>> 54, 196, 2*4, 256 NELT FB >>> 55, 3*4, 256 NELT FB >>> 56, 3*4, 256 NELT FB >>> 57, 3*4, 256 NELT FB >>> 58, 3*4, 256 NELT FB >>> 59, 3*4, 256 NELT FB >>> 60, 3*4, 256 NELT FB >>> 61, 3*4, 256 NELT FB >>> 62, 3*4, 256 NELT FB >>> 63, 3*4, 256 NELT FB >>> Application 419539 resources: utime ~8s, stime ~13s >>> >>> Does the code map in parallel here? I'm not sure what's happening here, >>> because the .map and .rea file do in fact agree. The error seems to >>> occur when processor #25 is mapped for a second time. The same thing >>> happens with my own cases that were running on a similar machine before >>> but with Nek compiled with PGI. >>> >>> Any help would be greatly appreciated >>> >>> Oliver >>> >>> _______________________________________________ >>> 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 > > > End of Nek5000-users Digest, Vol 35, Issue 21 > ********************************************* From nek5000-users at lists.mcs.anl.gov Wed Feb 1 11:04:09 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 1 Feb 2012 18:04:09 +0100 Subject: [Nek5000-users] Nek5000-users Digest, Vol 35, Issue 21 In-Reply-To: <4F2900A0.70601@iag.uni-stuttgart.de> References: <4F2900A0.70601@iag.uni-stuttgart.de> Message-ID: Oliver, We currently do not support the Cray compiler but we will work on it to make it happen. Need to check if I can get access to a Cray machine. In the meantime please use the PGI compiler on your Cray system. Variations in performance are typically low (around 10%) considering different compilers. At least for Nek5000 :) Cheers, Stefan On 2/1/12, nek5000-users at lists.mcs.anl.gov wrote: > Dear Stefan and Paul, > > Thank you for your replies. > > The code compiles nicely and the same case runs when I compile with PGI > (for some reason that wasn't the case with the older Nek version I used > before; it compiled but gave segmentation faults before creating any > other output). Cray people told me however that I should use crayftn for > better performance, at least for large cases. Any thoughts? > > Oliver >> Send Nek5000-users mailing list submissions to >> nek5000-users at lists.mcs.anl.gov >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> or, via email, send a message with subject or body 'help' to >> nek5000-users-request at lists.mcs.anl.gov >> >> You can reach the person managing the list at >> nek5000-users-owner at lists.mcs.anl.gov >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Nek5000-users digest..." >> >> >> Today's Topics: >> >> 1. Re: Running NEK on CRAY; compilation& running issues >> (nek5000-users at lists.mcs.anl.gov) >> 2. Re: Running NEK on CRAY; compilation& running issues >> (nek5000-users at lists.mcs.anl.gov) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 30 Jan 2012 19:02:23 +0100 >> From: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] Running NEK on CRAY; compilation& >> running issues >> To: nek5000-users at lists.mcs.anl.gov >> Message-ID: >> >> Content-Type: text/plain; charset=windows-1252 >> >> Hi Oliver, >> >> Can you try to use the PGI compiler instead of the Cray. Just want to >> check if this is a compiler specific issue. >> >> Cheers, >> Stefan >> >> On 1/30/12, nek5000-users at lists.mcs.anl.gov >> wrote: >>> Oliver, >>> >>> Thanks for your comments. We'll certainly take care of the >>> multd() and gsync() issues. >>> >>> We have what I believe is an xe6 on site and several users >>> are using it regularly. They may have some comments about >>> the flags, etc. and the issues that you are running into. >>> Hopefully, someone will get back to you early today. >>> >>> Regards, >>> >>> Paul >>> >>> >>> On Mon, 30 Jan 2012, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Dear NEKs, >>>> >>>> I'm currently trying to compile NEK via crayftn to run on a XE6 and I >>>> run into some issues. Some compilation problems I solved (with kind help >>>> of CRAY personnel). I'll mention them here as they can be part of the >>>> problem, I assume. >>>> >>>> 1) changed >>>> *ftn*) P="-r8 -Mpreprocess >>>> to *ftn*) P="-s real64 -eZ -em" >>>> for double precision reals and to invoke preprocessor in makenek.inc >>>> (Cray uses ftn command as a wrapper) >>>> >>>> 2) changed subroutine name ?gsync? to ?gsync_nek? in all source files >>>> as >>>> crayftn has a build-in routine of the same name that conflicts with >>>> Nek's gsync >>>> >>>> 3) changed calls to subroutine ?multd? from >>>> CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1) >>>> to CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1,0) >>>> in ?navier1.f? as crayftn complains about missing seventh argument >>>> ?iflg? (calls come from subroutine ?tmultd? which seems not to be >>>> called >>>> in the code, though) >>>> >>>> In the SIZE file I'm setting lelt=300, lelv=lelt, lp = 64, lelg = 300. >>>> With these changes I'm running the eddy_uv example via ?aprun -n 64 -N >>>> 32 ./nek5000? on 64 processors and I'm getting the following output: >>>> >>>> /----------------------------------------------------------\\ >>>> | _ __ ______ __ __ ______ ____ ____ ____ | >>>> | / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\ | >>>> | / |/ // __/ / ,< /___ \\ / / / // / / // / / / | >>>> | / /| // /___ / /| | ____/ / / /_/ // /_/ // /_/ / | >>>> | /_/ |_//_____//_/ |_|/_____/ \\____/ \\____/ \\____/ | >>>> | | >>>> |----------------------------------------------------------| >>>> | | >>>> | NEK5000: Open Source Spectral Element Solver | >>>> | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC | >>>> | Version: 1.0rc1 / SVN r730 | >>>> | Web: http://nek5000.mcs.anl.gov | >>>> | | >>>> \\----------------------------------------------------------/ >>>> >>>> >>>> Number of processors: 64 >>>> REAL wdsize : 8 >>>> INTEGER wdsize : 4 >>>> >>>> >>>> Beginning session: >>>> /zhome/academic/HLRS/iag/iagoschm/run_nek/eddy_example/eddy_uv.rea >>>> >>>> >>>> timer accuracy: 2.8610229E-07 sec >>>> >>>> read .rea file >>>> nelgt/nelgv/lelt: 256 256 300 >>>> lx1 /lx2 /lx3 : 8 6 8 >>>> >>>> mapping elements to processors >>>> 0, 2*4, 2*256 NELV >>>> 1, 2*4, 2*256 NELV >>>> 8, 2*4, 2*256 NELV >>>> 9, 2*4, 2*256 NELV >>>> 17, 2*4, 2*256 NELV >>>> 16, 2*4, 2*256 NELV >>>> 20, 2*4, 2*256 NELV >>>> 3*4, 2*256 NELV >>>> 29, 2*4, 2*256 NELV >>>> 21, 2*4, 2*256 NELV >>>> 28, 2*4, 2*256 NELV >>>> 7, 2*4, 2*256 NELV >>>> 31, 2*4, 2*256 NELV >>>> 25, 2*4, 2*256 NELV >>>> 11, 2*4, 2*256 NELV >>>> 12, 2*4, 2*256 NELV >>>> 6, 2*4, 2*256 NELV >>>> 30, 2*4, 2*256 NELV >>>> 18, 2*4, 2*256 NELV >>>> 19, 2*4, 2*256 NELV >>>> 2, 2*4, 2*256 NELV >>>> 5, 2*4, 2*256 NELV >>>> 23, 2*4, 2*256 NELV >>>> 27, 2*4, 2*256 NELV >>>> 10, 2*4, 2*256 NELV >>>> 22, 2*4, 2*256 NELV >>>> 13, 2*4, 2*256 NELV >>>> 14, 2*4, 2*256 NELV >>>> 15, 2*4, 2*256 NELV >>>> 3, 2*4, 2*256 NELV >>>> 26, 2*4, 2*256 NELV >>>> 24, 2*4, 2*256 NELV >>>> 33, 2*4, 2*256 NELV >>>> 41, 2*4, 2*256 NELV >>>> 32, 2*4, 2*256 NELV >>>> 40, 2*4, 2*256 NELV >>>> 45, 2*4, 2*256 NELV >>>> 44, 2*4, 2*256 NELV >>>> 49, 2*4, 2*256 NELV >>>> 34, 2*4, 2*256 NELV >>>> 35, 2*4, 2*256 NELV >>>> 48, 2*4, 2*256 NELV >>>> 39, 2*4, 2*256 NELV >>>> 38, 2*4, 2*256 NELV >>>> 50, 2*4, 2*256 NELV >>>> 51, 2*4, 2*256 NELV >>>> 37, 2*4, 2*256 NELV >>>> 36, 2*4, 2*256 NELV >>>> 55, 2*4, 2*256 NELV >>>> 54, 2*4, 2*256 NELV >>>> 57, 2*4, 2*256 NELV >>>> 58, 2*4, 2*256 NELV >>>> 43, 2*4, 2*256 NELV >>>> 42, 2*4, 2*256 NELV >>>> 47, 2*4, 2*256 NELV >>>> 53, 2*4, 2*256 NELV >>>> 59, 2*4, 2*256 NELV >>>> 46, 2*4, 2*256 NELV >>>> 60, 2*4, 2*256 NELV >>>> 61, 2*4, 2*256 NELV >>>> 63, 2*4, 2*256 NELV >>>> 62, 2*4, 2*256 NELV >>>> 52, 2*4, 2*256 NELV >>>> 56, 2*4, 2*256 NELV >>>> 25, 0, 2*4, 256 NELT FAIL >>>> 24, 0, 2*4, 256 NELT FAIL >>>> 21, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 20, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 31, 0, 2*4, 256 NELT FAIL >>>> 8, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 17, 0, 2*4, 256 NELT FAIL >>>> 14, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 15, 0, 2*4, 256 NELT FAIL >>>> 16, 0, 2*4, 256 NELT FAIL >>>> 26, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 10, 0, 2*4, 256 NELT FAIL >>>> 2, 0, 2*4, 256 NELT FAIL >>>> 30, 0, 2*4, 256 NELT FAIL >>>> 11, 0, 2*4, 256 NELT FAIL >>>> 7, 0, 2*4, 256 NELT FAIL >>>> 1, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 2*0, 2*4, 256 NELT FAIL >>>> 6, 0, 2*4, 256 NELT FAIL >>>> 4, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 13, 0, 2*4, 256 NELT FAIL >>>> 12, 0, 2*4, 256 NELT FAIL >>>> 28, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 18, 0, 2*4, 256 NELT FAIL >>>> 29, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 23, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 27, 0, 2*4, 256 NELT FAIL >>>> 3, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 19, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 5, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 22, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 2*0, 2*4, 256 NELT FB >>>> 1, 0, 2*4, 256 NELT FB >>>> 2, 0, 2*4, 256 NELT FB >>>> 3, 0, 2*4, 256 NELT FB >>>> 4, 0, 2*4, 256 NELT FB >>>> 5, 0, 2*4, 256 NELT FB >>>> 6, 0, 2*4, 256 NELT FB >>>> 7, 0, 2*4, 256 NELT FB >>>> 8, 0, 2*4, 256 NELT FB >>>> 9, 3*4, 256 NELT FB >>>> 10, 0, 2*4, 256 NELT FB >>>> 11, 0, 2*4, 256 NELT FB >>>> 12, 0, 2*4, 256 NELT FB >>>> 13, 0, 2*4, 256 NELT FB >>>> 14, 0, 2*4, 256 NELT FB >>>> 15, 0, 2*4, 256 NELT FB >>>> 16, 0, 2*4, 256 NELT FB >>>> 17, 0, 2*4, 256 NELT FB >>>> 18, 0, 2*4, 256 NELT FB >>>> 19, 0, 2*4, 256 NELT FB >>>> 20, 0, 2*4, 256 NELT FB >>>> 21, 0, 2*4, 256 NELT FB >>>> 22, 0, 2*4, 256 NELT FB >>>> 23, 0, 2*4, 256 NELT FB >>>> 24, 0, 2*4, 256 NELT FB >>>> 25, 0, 2*4, 256 NELT FB >>>> 26, 0, 2*4, 256 NELT FB >>>> 27, 0, 2*4, 256 NELT FB >>>> 28, 0, 2*4, 256 NELT FB >>>> 29, 0, 2*4, 256 NELT FB >>>> 30, 0, 2*4, 256 NELT FB >>>> 31, 0, 2*4, 256 NELT FB >>>> >>>> call exitt: dying ... >>>> >>>> backtrace(): obtained 1 stack frames. >>>> [0x662a40] >>>> >>>> total elapsed time : 7.82199E-02 sec >>>> total solver time incl. I/O : 0.00000E+00 sec >>>> time/timestep : 0.00000E+00 sec >>>> CPU seconds/timestep/gridpt : 0.00000E+00 sec >>>> >>>> 39, 0, 2*4, 256 NELT FAIL >>>> 38, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 36, 0, 2*4, 256 NELT FAIL >>>> 41, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 32, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 48, 0, 2*4, 256 NELT FAIL >>>> 34, 0, 2*4, 256 NELT FAIL >>>> 54, 196, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 40, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 46, 0, 2*4, 256 NELT FAIL >>>> 47, 0, 2*4, 256 NELT FAIL >>>> 33, 0, 2*4, 256 NELT FAIL >>>> 37, 0, 2*4, 256 NELT FAIL >>>> 35, 0, 2*4, 256 NELT FAIL >>>> 43, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 45, 0, 2*4, 256 NELT FAIL >>>> 42, 0, 2*4, 256 NELT FAIL >>>> 44, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 32, 0, 2*4, 256 NELT FB >>>> 33, 0, 2*4, 256 NELT FB >>>> 34, 0, 2*4, 256 NELT FB >>>> 35, 0, 2*4, 256 NELT FB >>>> 36, 0, 2*4, 256 NELT FB >>>> 37, 0, 2*4, 256 NELT FB >>>> 38, 0, 2*4, 256 NELT FB >>>> 39, 0, 2*4, 256 NELT FB >>>> 40, 0, 2*4, 256 NELT FB >>>> 41, 0, 2*4, 256 NELT FB >>>> 42, 0, 2*4, 256 NELT FB >>>> 43, 0, 2*4, 256 NELT FB >>>> 44, 0, 2*4, 256 NELT FB >>>> 45, 0, 2*4, 256 NELT FB >>>> 46, 0, 2*4, 256 NELT FB >>>> 47, 0, 2*4, 256 NELT FB >>>> 48, 0, 2*4, 256 NELT FB >>>> 49, 3*4, 256 NELT FB >>>> 50, 3*4, 256 NELT FB >>>> 51, 3*4, 256 NELT FB >>>> 52, 3*4, 256 NELT FB >>>> 53, 3*4, 256 NELT FB >>>> 54, 196, 2*4, 256 NELT FB >>>> 55, 3*4, 256 NELT FB >>>> 56, 3*4, 256 NELT FB >>>> 57, 3*4, 256 NELT FB >>>> 58, 3*4, 256 NELT FB >>>> 59, 3*4, 256 NELT FB >>>> 60, 3*4, 256 NELT FB >>>> 61, 3*4, 256 NELT FB >>>> 62, 3*4, 256 NELT FB >>>> 63, 3*4, 256 NELT FB >>>> Application 419539 resources: utime ~8s, stime ~13s >>>> >>>> Does the code map in parallel here? I'm not sure what's happening here, >>>> because the .map and .rea file do in fact agree. The error seems to >>>> occur when processor #25 is mapped for a second time. The same thing >>>> happens with my own cases that were running on a similar machine before >>>> but with Nek compiled with PGI. >>>> >>>> Any help would be greatly appreciated >>>> >>>> Oliver >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 30 Jan 2012 13:43:50 -0600 (CST) >> From: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] Running NEK on CRAY; compilation& >> running issues >> To: nek5000-users at lists.mcs.anl.gov >> Message-ID: >> <304748520.192593.1327952630495.JavaMail.root at zimbra.anl.gov> >> Content-Type: text/plain; charset=utf-8 >> >> Hi Oliver, >> >> I have been using Cray xe6/xt6 successfully with PGI compilers specified >> in makenek with >> >> # Fortran compiler >> F77="ftn" >> >> # C compiler >> CC="cc" >> >> and the submission script I use is below. >> >> Best. >> Aleks >> >> >> rm *batch* >> echo $1> SESSION.NAME >> echo `pwd`'/'>> SESSION.NAME >> touch $1.rea >> rm -f ioinfo >> mv -f $1.log.$2 $1.log1.$2 >> mv -f $1.his $1.his1 >> mv -f $1.sch $1.sch1 >> rm -f logfile >> echo ''> $1.log.$2 >> echo "#!/bin/bash"> $1.batch >> echo "#PBS -l mppwidth="$2>> $1.batch >> echo "#PBS -l walltime="$3":"$4":00">> $1.batch >> echo "#PBS -j oe">> $1.batch >> echo cd `pwd`>> $1.batch >> echo aprun -n $2 ./nek5000 ">>" $1.log.$2>> $1.batch >> echo "exit 0;">> $1.batch >> qsub -q batch $1.batch >> sleep 3 >> ln $1.log.$2 logfile >> ## >> ## usage: neke case cores hours minutes >> >> >> >> >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Monday, January 30, 2012 12:02:23 PM >> Subject: Re: [Nek5000-users] Running NEK on CRAY; compilation& running >> issues >> >> Hi Oliver, >> >> Can you try to use the PGI compiler instead of the Cray. Just want to >> check if this is a compiler specific issue. >> >> Cheers, >> Stefan >> >> On 1/30/12, nek5000-users at lists.mcs.anl.gov >> wrote: >>> Oliver, >>> >>> Thanks for your comments. We'll certainly take care of the >>> multd() and gsync() issues. >>> >>> We have what I believe is an xe6 on site and several users >>> are using it regularly. They may have some comments about >>> the flags, etc. and the issues that you are running into. >>> Hopefully, someone will get back to you early today. >>> >>> Regards, >>> >>> Paul >>> >>> >>> On Mon, 30 Jan 2012, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Dear NEKs, >>>> >>>> I'm currently trying to compile NEK via crayftn to run on a XE6 and I >>>> run into some issues. Some compilation problems I solved (with kind help >>>> of CRAY personnel). I'll mention them here as they can be part of the >>>> problem, I assume. >>>> >>>> 1) changed >>>> *ftn*) P="-r8 -Mpreprocess >>>> to *ftn*) P="-s real64 -eZ -em" >>>> for double precision reals and to invoke preprocessor in makenek.inc >>>> (Cray uses ftn command as a wrapper) >>>> >>>> 2) changed subroutine name ?gsync? to ?gsync_nek? in all source files >>>> as >>>> crayftn has a build-in routine of the same name that conflicts with >>>> Nek's gsync >>>> >>>> 3) changed calls to subroutine ?multd? from >>>> CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1) >>>> to CALL MULTD (TA1,TVX,RXM2,SXM2,TXM2,1,0) >>>> in ?navier1.f? as crayftn complains about missing seventh argument >>>> ?iflg? (calls come from subroutine ?tmultd? which seems not to be >>>> called >>>> in the code, though) >>>> >>>> In the SIZE file I'm setting lelt=300, lelv=lelt, lp = 64, lelg = 300. >>>> With these changes I'm running the eddy_uv example via ?aprun -n 64 -N >>>> 32 ./nek5000? on 64 processors and I'm getting the following output: >>>> >>>> /----------------------------------------------------------\\ >>>> | _ __ ______ __ __ ______ ____ ____ ____ | >>>> | / | / // ____// //_/ / ____/ / __ \\ / __ \\ / __ \\ | >>>> | / |/ // __/ / ,< /___ \\ / / / // / / // / / / | >>>> | / /| // /___ / /| | ____/ / / /_/ // /_/ // /_/ / | >>>> | /_/ |_//_____//_/ |_|/_____/ \\____/ \\____/ \\____/ | >>>> | | >>>> |----------------------------------------------------------| >>>> | | >>>> | NEK5000: Open Source Spectral Element Solver | >>>> | COPYRIGHT (c) 2008-2010 UCHICAGO ARGONNE, LLC | >>>> | Version: 1.0rc1 / SVN r730 | >>>> | Web: http://nek5000.mcs.anl.gov | >>>> | | >>>> \\----------------------------------------------------------/ >>>> >>>> >>>> Number of processors: 64 >>>> REAL wdsize : 8 >>>> INTEGER wdsize : 4 >>>> >>>> >>>> Beginning session: >>>> /zhome/academic/HLRS/iag/iagoschm/run_nek/eddy_example/eddy_uv.rea >>>> >>>> >>>> timer accuracy: 2.8610229E-07 sec >>>> >>>> read .rea file >>>> nelgt/nelgv/lelt: 256 256 300 >>>> lx1 /lx2 /lx3 : 8 6 8 >>>> >>>> mapping elements to processors >>>> 0, 2*4, 2*256 NELV >>>> 1, 2*4, 2*256 NELV >>>> 8, 2*4, 2*256 NELV >>>> 9, 2*4, 2*256 NELV >>>> 17, 2*4, 2*256 NELV >>>> 16, 2*4, 2*256 NELV >>>> 20, 2*4, 2*256 NELV >>>> 3*4, 2*256 NELV >>>> 29, 2*4, 2*256 NELV >>>> 21, 2*4, 2*256 NELV >>>> 28, 2*4, 2*256 NELV >>>> 7, 2*4, 2*256 NELV >>>> 31, 2*4, 2*256 NELV >>>> 25, 2*4, 2*256 NELV >>>> 11, 2*4, 2*256 NELV >>>> 12, 2*4, 2*256 NELV >>>> 6, 2*4, 2*256 NELV >>>> 30, 2*4, 2*256 NELV >>>> 18, 2*4, 2*256 NELV >>>> 19, 2*4, 2*256 NELV >>>> 2, 2*4, 2*256 NELV >>>> 5, 2*4, 2*256 NELV >>>> 23, 2*4, 2*256 NELV >>>> 27, 2*4, 2*256 NELV >>>> 10, 2*4, 2*256 NELV >>>> 22, 2*4, 2*256 NELV >>>> 13, 2*4, 2*256 NELV >>>> 14, 2*4, 2*256 NELV >>>> 15, 2*4, 2*256 NELV >>>> 3, 2*4, 2*256 NELV >>>> 26, 2*4, 2*256 NELV >>>> 24, 2*4, 2*256 NELV >>>> 33, 2*4, 2*256 NELV >>>> 41, 2*4, 2*256 NELV >>>> 32, 2*4, 2*256 NELV >>>> 40, 2*4, 2*256 NELV >>>> 45, 2*4, 2*256 NELV >>>> 44, 2*4, 2*256 NELV >>>> 49, 2*4, 2*256 NELV >>>> 34, 2*4, 2*256 NELV >>>> 35, 2*4, 2*256 NELV >>>> 48, 2*4, 2*256 NELV >>>> 39, 2*4, 2*256 NELV >>>> 38, 2*4, 2*256 NELV >>>> 50, 2*4, 2*256 NELV >>>> 51, 2*4, 2*256 NELV >>>> 37, 2*4, 2*256 NELV >>>> 36, 2*4, 2*256 NELV >>>> 55, 2*4, 2*256 NELV >>>> 54, 2*4, 2*256 NELV >>>> 57, 2*4, 2*256 NELV >>>> 58, 2*4, 2*256 NELV >>>> 43, 2*4, 2*256 NELV >>>> 42, 2*4, 2*256 NELV >>>> 47, 2*4, 2*256 NELV >>>> 53, 2*4, 2*256 NELV >>>> 59, 2*4, 2*256 NELV >>>> 46, 2*4, 2*256 NELV >>>> 60, 2*4, 2*256 NELV >>>> 61, 2*4, 2*256 NELV >>>> 63, 2*4, 2*256 NELV >>>> 62, 2*4, 2*256 NELV >>>> 52, 2*4, 2*256 NELV >>>> 56, 2*4, 2*256 NELV >>>> 25, 0, 2*4, 256 NELT FAIL >>>> 24, 0, 2*4, 256 NELT FAIL >>>> 21, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 20, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 31, 0, 2*4, 256 NELT FAIL >>>> 8, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 17, 0, 2*4, 256 NELT FAIL >>>> 14, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 15, 0, 2*4, 256 NELT FAIL >>>> 16, 0, 2*4, 256 NELT FAIL >>>> 26, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 10, 0, 2*4, 256 NELT FAIL >>>> 2, 0, 2*4, 256 NELT FAIL >>>> 30, 0, 2*4, 256 NELT FAIL >>>> 11, 0, 2*4, 256 NELT FAIL >>>> 7, 0, 2*4, 256 NELT FAIL >>>> 1, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 2*0, 2*4, 256 NELT FAIL >>>> 6, 0, 2*4, 256 NELT FAIL >>>> 4, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 13, 0, 2*4, 256 NELT FAIL >>>> 12, 0, 2*4, 256 NELT FAIL >>>> 28, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 18, 0, 2*4, 256 NELT FAIL >>>> 29, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 23, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 27, 0, 2*4, 256 NELT FAIL >>>> 3, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 19, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 5, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 22, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 2*0, 2*4, 256 NELT FB >>>> 1, 0, 2*4, 256 NELT FB >>>> 2, 0, 2*4, 256 NELT FB >>>> 3, 0, 2*4, 256 NELT FB >>>> 4, 0, 2*4, 256 NELT FB >>>> 5, 0, 2*4, 256 NELT FB >>>> 6, 0, 2*4, 256 NELT FB >>>> 7, 0, 2*4, 256 NELT FB >>>> 8, 0, 2*4, 256 NELT FB >>>> 9, 3*4, 256 NELT FB >>>> 10, 0, 2*4, 256 NELT FB >>>> 11, 0, 2*4, 256 NELT FB >>>> 12, 0, 2*4, 256 NELT FB >>>> 13, 0, 2*4, 256 NELT FB >>>> 14, 0, 2*4, 256 NELT FB >>>> 15, 0, 2*4, 256 NELT FB >>>> 16, 0, 2*4, 256 NELT FB >>>> 17, 0, 2*4, 256 NELT FB >>>> 18, 0, 2*4, 256 NELT FB >>>> 19, 0, 2*4, 256 NELT FB >>>> 20, 0, 2*4, 256 NELT FB >>>> 21, 0, 2*4, 256 NELT FB >>>> 22, 0, 2*4, 256 NELT FB >>>> 23, 0, 2*4, 256 NELT FB >>>> 24, 0, 2*4, 256 NELT FB >>>> 25, 0, 2*4, 256 NELT FB >>>> 26, 0, 2*4, 256 NELT FB >>>> 27, 0, 2*4, 256 NELT FB >>>> 28, 0, 2*4, 256 NELT FB >>>> 29, 0, 2*4, 256 NELT FB >>>> 30, 0, 2*4, 256 NELT FB >>>> 31, 0, 2*4, 256 NELT FB >>>> >>>> call exitt: dying ... >>>> >>>> backtrace(): obtained 1 stack frames. >>>> [0x662a40] >>>> >>>> total elapsed time : 7.82199E-02 sec >>>> total solver time incl. I/O : 0.00000E+00 sec >>>> time/timestep : 0.00000E+00 sec >>>> CPU seconds/timestep/gridpt : 0.00000E+00 sec >>>> >>>> 39, 0, 2*4, 256 NELT FAIL >>>> 38, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 36, 0, 2*4, 256 NELT FAIL >>>> 41, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 32, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 48, 0, 2*4, 256 NELT FAIL >>>> 34, 0, 2*4, 256 NELT FAIL >>>> 54, 196, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> 40, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 46, 0, 2*4, 256 NELT FAIL >>>> 47, 0, 2*4, 256 NELT FAIL >>>> 33, 0, 2*4, 256 NELT FAIL >>>> 37, 0, 2*4, 256 NELT FAIL >>>> 35, 0, 2*4, 256 NELT FAIL >>>> 43, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 45, 0, 2*4, 256 NELT FAIL >>>> 42, 0, 2*4, 256 NELT FAIL >>>> 44, 0, 2*4, 256 NELT FAIL >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> Check that .map file and .rea file agree >>>> 32, 0, 2*4, 256 NELT FB >>>> 33, 0, 2*4, 256 NELT FB >>>> 34, 0, 2*4, 256 NELT FB >>>> 35, 0, 2*4, 256 NELT FB >>>> 36, 0, 2*4, 256 NELT FB >>>> 37, 0, 2*4, 256 NELT FB >>>> 38, 0, 2*4, 256 NELT FB >>>> 39, 0, 2*4, 256 NELT FB >>>> 40, 0, 2*4, 256 NELT FB >>>> 41, 0, 2*4, 256 NELT FB >>>> 42, 0, 2*4, 256 NELT FB >>>> 43, 0, 2*4, 256 NELT FB >>>> 44, 0, 2*4, 256 NELT FB >>>> 45, 0, 2*4, 256 NELT FB >>>> 46, 0, 2*4, 256 NELT FB >>>> 47, 0, 2*4, 256 NELT FB >>>> 48, 0, 2*4, 256 NELT FB >>>> 49, 3*4, 256 NELT FB >>>> 50, 3*4, 256 NELT FB >>>> 51, 3*4, 256 NELT FB >>>> 52, 3*4, 256 NELT FB >>>> 53, 3*4, 256 NELT FB >>>> 54, 196, 2*4, 256 NELT FB >>>> 55, 3*4, 256 NELT FB >>>> 56, 3*4, 256 NELT FB >>>> 57, 3*4, 256 NELT FB >>>> 58, 3*4, 256 NELT FB >>>> 59, 3*4, 256 NELT FB >>>> 60, 3*4, 256 NELT FB >>>> 61, 3*4, 256 NELT FB >>>> 62, 3*4, 256 NELT FB >>>> 63, 3*4, 256 NELT FB >>>> Application 419539 resources: utime ~8s, stime ~13s >>>> >>>> Does the code map in parallel here? I'm not sure what's happening here, >>>> because the .map and .rea file do in fact agree. The error seems to >>>> occur when processor #25 is mapped for a second time. The same thing >>>> happens with my own cases that were running on a similar machine before >>>> but with Nek compiled with PGI. >>>> >>>> Any help would be greatly appreciated >>>> >>>> Oliver >>>> >>>> _______________________________________________ >>>> 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 >> >> >> End of Nek5000-users Digest, Vol 35, Issue 21 >> ********************************************* > > _______________________________________________ > 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 Feb 5 10:59:52 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 5 Feb 2012 17:59:52 +0100 Subject: [Nek5000-users] Oscillatory Cylinder Message-ID: <58CFDFCB-734C-45AD-BF6E-873307D04580@mech.kth.se> Hi Neks I am trying to set up a case in nekton to model an oscillatory cylinder in nekton, I've done some reading on possible ways do to it, and I was wondering if a similar problem has been performed with nekton and what sorts of boundary conditions were used. The cylinder oscillates with a small amplitude with respect to its diameter. Cheers Armin From nek5000-users at lists.mcs.anl.gov Tue Feb 7 08:05:16 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 7 Feb 2012 08:05:16 -0600 Subject: [Nek5000-users] Boundary condition for a passive scalar? Message-ID: Hello, I am trying simulate a backward facing step flow at Re = 5000 with a passive scalar using Schmidt number = 0.71. I am having some trouble with the boundary condition for the passive scalars. At the wall I use zero gradient boundary condition by using insulated boundary ("I ") as the flag in the .rea file. After several flow thorough times, the passive scalars just fill the domain up and become uniform everywhere. This can be observed from the following 2 movies. 1. This is the contour plot of the passive scalar. The "Min" value of the scalar concentration keeps increasing. http://www2.uic.edu/~hkanch1/s2.mpeg 2. In this movie, the "Min" value of scalar is fixed. It can be observed that the scalar concentration is becoming uniform throughout the domain. http://www2.uic.edu/~hkanch1/s3.mpeg The simulation works just fine if I set the passive scalar value to "zero" on the wall. http://www2.uic.edu/~hkanch1/s4.mpeg I don't understand why this is happening. May be something wrong in my set up of the problem. Regards, Harish. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Feb 10 16:04:59 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 10 Feb 2012 17:04:59 -0500 Subject: [Nek5000-users] Evaluate the validity of simulation results Message-ID: <977E8EBAA2E5E946A9311B0F429730FA7279E8F9D4@EXCHMBB.ornl.gov> Hi guys. I am a computer science guy without any background in fluid dynamics solver. I am using Nek5000 for the fault tolerance research. In particular, I inject random errors into data structures of Nek5000 and then record how Nek5000 reacts. Currently, I have a problem about how to judge the performance of Nek5K with injected faults is normal (i.e., tolerating fault) or not. I can simply record the execution time and then compare time difference. However, some injected errors might not lead to time variance while making the simulation result invalid. Is there any metric I can use to evaluate if the simulation result is valid/reasonable (especially for the eddy and/or vortex problem)? For example, a X error rate beyond a threshold after a fixed number of timesteps, or something? Thank you very much. -Dong -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Feb 14 08:08:35 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 14 Feb 2012 09:08:35 -0500 Subject: [Nek5000-users] Vanishing Jacobians while using moving mesh In-Reply-To: References: Message-ID: Hi Neks, I'm trying to simulate 2D flow over an oscillating cylinder using moving mesh, and tried to set up a test case by looking at the peris example. I however am getting vanishing Jacobians after the first few timesteps. I am modifying the the boundary velocity of the cylinder in userbc instead of userchk (as in the peris example). Would it be possible for you to look at my .usr file and tell me what I am doing wrong? I have attached the .rea, .usr, and SIZE with this mail. Further, when I try to view the mesh of the output (or the xyz fld outputfile) in visit, visit crashes with the following error: VisIt's viewer exited abnormally! Aborting the Graphical User Interface. Lastly, would it be possible to simulate moving walls with large deformations (i.e. where multiple elements get deformed), where the deformation is known ahead of time? (eg. a flapping aerofoil) Thank you for your help! Regards, Pradeep Extract from logfile: 60 U-PRES gmres: 100 7.5345E+42 1.0000E-02 4.0062E+57 6.7556E-03 1.5093E-02 ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 60 DNORM, DIVEX 1.18120867781751263E+043 7.53448962619089522E+042 60 6.0000E-02 1.6697E-02 Fluid done DT/DTCFL/DTFS/DTINIT 0.635E-45 0.635E-45 0.000E+00 0.100E-02 Step 61, t= 6.0800000E-02, DT= 8.0000000E-04, C=******* 2.2667E-01 1.8287E-02 Solving for fluid 3 ERROR: Vanishing Jacobian near 2th node of element 3. 2 ERROR: Vanishing Jacobian near 2th node of element 1. 2.27348348709230109E+081 -5.12478988977734591E+080 -2.60483379627720531E+079 3.21465902039155941E+039 3 xyz: -5.30056E+39 -5.84642E+39 3 xyz: -5.24850E+39 -6.93109E+39 3 ERROR: Vanishing Jacobian near 2th node of element 4. 2 xyz: 1.25061E+38 4.64957E+39 9.79493533554062390E+080 -3.01548938509156252E+080 2 xyz: -2.46589E-08 -5.64092E-01 3 xyz: -5.30056E+39 -5.84642E+39 3 xyz: -5.24850E+39 -6.93109E+39 2 ERROR: Vanishing Jacobian near 3th node of element 2. 3 ERROR: Vanishing Jacobian near 2th node of element 5. 1.43125817410005932E+039 -6.03607926692375119E+038 5.54918579647991880E+039 -1.67302572815141788E+039 3 xyz: -5.30056E+39 -5.84642E+39 2 xyz: -2.46589E-08 -5.64092E-01 3 xyz: -5.24850E+39 -6.93109E+39 3 ERROR: Vanishing Jacobian near 2th node of element 6. 2 xyz: -3.07794E-08 -7.04112E-01 2 ERROR: Vanishing Jacobian near 7th node of element 7. 8.35923896949543198E+038 -3.55455289325888722E+038 3 xyz: -5.30056E+39 -5.84642E+39 1.21747337192549314E+039 -1.79454406120891328E+038 3 xyz: -5.24850E+39 -6.93109E+39 2 xyz: -5.66434E-08 -1.29581E+00 2 xyz: -6.27639E-08 -1.43583E+00 2 ERROR: Vanishing Jacobian near 9th node of element 8. 1.17802538305091326E+039 -4.21489851051369387E+038 2 xyz: -6.55671E-08 -1.49996E+00 2 xyz: -3.25016E+38 4.93026E+39 call outfld: ifpsco: F 61 6.0800E-02 Write checkpoint: 61 6.0800E-02 OPEN: xyzcyl2.fld01 Jac error 1, setting p66=4, ifxyo=t call exitt: dying ... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cyl2.rea Type: application/octet-stream Size: 27227 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cyl2.usr Type: application/octet-stream Size: 5078 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SIZE Type: application/octet-stream Size: 3125 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Tue Feb 14 09:02:37 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 14 Feb 2012 16:02:37 +0100 Subject: [Nek5000-users] ON boundary condition Message-ID: <1329231757.21133.58.camel@skagsnebb.mech.kth.se> Hi all I try to find some information about ON boundary condition in nekton. What is the difference between O and ON? Regards Adam From nek5000-users at lists.mcs.anl.gov Wed Feb 15 08:33:31 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 15 Feb 2012 08:33:31 -0600 (CST) Subject: [Nek5000-users] ON boundary condition In-Reply-To: <1329231757.21133.58.camel@skagsnebb.mech.kth.se> References: <1329231757.21133.58.camel@skagsnebb.mech.kth.se> Message-ID: Hi Adam, I set up ON bc some years back to support Blasius boundary layer analysis in which the tangential (streamwise) velocity is prescribed and the wall-normal velocity is allowed to escape as the velocity boundary layer thickens. This also implies that the pressure is fixed on the upper surface. This feature was developed for Pn-Pn-2 and hasn't been extensively tested in many years. If this is a feature that you need, we could look into resurrecting it. (Note that the "escaping" feature implies that the surface is aligned with either x,y, or z, and not inclined w.r.t. these principal axes.) Cheers, Paul On Tue, 14 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi all > > I try to find some information about ON boundary condition in nekton. > What is the difference between O and ON? > Regards > > Adam > > _______________________________________________ > 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 Feb 15 08:34:33 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 15 Feb 2012 08:34:33 -0600 (CST) Subject: [Nek5000-users] Vanishing Jacobians while using moving mesh In-Reply-To: References: Message-ID: Pradeep, Start by setting p93-95 to 0 in your .rea file. I'll look at the rest of your setup today. Cheers, Paul On Tue, 14 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > I'm trying to simulate 2D flow over an oscillating cylinder using moving > mesh, and tried to set up a test case by looking at the peris example. I > however am getting vanishing Jacobians after the first few timesteps. > > I am modifying the the boundary velocity of the cylinder in userbc instead > of userchk (as in the peris example). Would it be possible for you to look > at my .usr file and tell me what I am doing wrong? > > I have attached the .rea, .usr, and SIZE with this mail. > > Further, when I try to view the mesh of the output (or the xyz fld > outputfile) in visit, visit crashes with the following error: > VisIt's viewer exited abnormally! Aborting the Graphical User Interface. > > Lastly, would it be possible to simulate moving walls with large > deformations (i.e. where multiple elements get deformed), where the > deformation is known ahead of time? (eg. a flapping aerofoil) > > Thank you for your help! > > Regards, > Pradeep > > Extract from logfile: > > 60 U-PRES gmres: 100 7.5345E+42 1.0000E-02 4.0062E+57 > 6.7556E-03 1.5093E-02 > ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 > ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 > ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 > ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 > 60 DNORM, DIVEX 1.18120867781751263E+043 > 7.53448962619089522E+042 > 60 6.0000E-02 1.6697E-02 Fluid done > DT/DTCFL/DTFS/DTINIT 0.635E-45 0.635E-45 0.000E+00 0.100E-02 > Step 61, t= 6.0800000E-02, DT= 8.0000000E-04, C=******* 2.2667E-01 > 1.8287E-02 > Solving for fluid > > > 3 ERROR: Vanishing Jacobian near 2th node of element 3. > > > 2 ERROR: Vanishing Jacobian near 2th node of element 1. > 2.27348348709230109E+081 -5.12478988977734591E+080 > -2.60483379627720531E+079 3.21465902039155941E+039 > 3 xyz: -5.30056E+39 -5.84642E+39 > 3 xyz: -5.24850E+39 -6.93109E+39 > > > 3 ERROR: Vanishing Jacobian near 2th node of element 4. > 2 xyz: 1.25061E+38 4.64957E+39 > 9.79493533554062390E+080 -3.01548938509156252E+080 > 2 xyz: -2.46589E-08 -5.64092E-01 > > > 3 xyz: -5.30056E+39 -5.84642E+39 > 3 xyz: -5.24850E+39 -6.93109E+39 > 2 ERROR: Vanishing Jacobian near 3th node of element 2. > > > 3 ERROR: Vanishing Jacobian near 2th node of element 5. > 1.43125817410005932E+039 -6.03607926692375119E+038 > 5.54918579647991880E+039 -1.67302572815141788E+039 > 3 xyz: -5.30056E+39 -5.84642E+39 > 2 xyz: -2.46589E-08 -5.64092E-01 > 3 xyz: -5.24850E+39 -6.93109E+39 > > > 3 ERROR: Vanishing Jacobian near 2th node of element 6. > 2 xyz: -3.07794E-08 -7.04112E-01 > > > 2 ERROR: Vanishing Jacobian near 7th node of element 7. > 8.35923896949543198E+038 -3.55455289325888722E+038 > 3 xyz: -5.30056E+39 -5.84642E+39 > 1.21747337192549314E+039 -1.79454406120891328E+038 > 3 xyz: -5.24850E+39 -6.93109E+39 > 2 xyz: -5.66434E-08 -1.29581E+00 > 2 xyz: -6.27639E-08 -1.43583E+00 > > > 2 ERROR: Vanishing Jacobian near 9th node of element 8. > 1.17802538305091326E+039 -4.21489851051369387E+038 > 2 xyz: -6.55671E-08 -1.49996E+00 > 2 xyz: -3.25016E+38 4.93026E+39 > call outfld: ifpsco: F > > 61 6.0800E-02 Write checkpoint: > > 61 6.0800E-02 OPEN: > xyzcyl2.fld01 > > Jac error 1, setting p66=4, ifxyo=t > > call exitt: dying ... > From nek5000-users at lists.mcs.anl.gov Wed Feb 15 08:39:10 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 15 Feb 2012 08:39:10 -0600 Subject: [Nek5000-users] Vanishing Jacobians while using moving mesh In-Reply-To: References: Message-ID: Pradeep, Which version of Visit are you using? We have experienced similar issues with version 2.4 when viewing 2D meshes. If this is the case, try using 2.3.2 and see if you have the same problem. Josh On Tue, Feb 14, 2012 at 8:08 AM, wrote: > Hi Neks, > > I'm trying to simulate 2D flow over an oscillating cylinder using moving > mesh, and tried to set up a test case by looking at the peris example. I > however am getting vanishing Jacobians after the first few timesteps. > > I am modifying the the boundary velocity of the cylinder in userbc instead > of userchk (as in the peris example). Would it be possible for you to look > at my .usr file and tell me what I am doing wrong? > > I have attached the .rea, .usr, and SIZE with this mail. > > Further, when I try to view the mesh of the output (or the xyz fld > outputfile) in visit, visit crashes with the following error: > VisIt's viewer exited abnormally! Aborting the Graphical User Interface. > > Lastly, would it be possible to simulate moving walls with large > deformations (i.e. where multiple elements get deformed), where the > deformation is known ahead of time? (eg. a flapping aerofoil) > > Thank you for your help! > > Regards, > Pradeep > > Extract from logfile: > > ??????? 60 U-PRES gmres:??? 100? 7.5345E+42? 1.0000E-02? 4.0062E+57 > 6.7556E-03? 1.5093E-02 > ?ERROR:? alphad .le. 0 in econjp -1.31175831444004495E+179????????? 16 > ?ERROR:? alphad .le. 0 in econjp -1.31175831444004495E+179????????? 16 > ?ERROR:? alphad .le. 0 in econjp -1.31175831444004495E+179????????? 16 > ?ERROR:? alphad .le. 0 in econjp -1.31175831444004495E+179????????? 16 > ????????? 60? DNORM, DIVEX? 1.18120867781751263E+043 > 7.53448962619089522E+042 > ???????? 60?? 6.0000E-02? 1.6697E-02 Fluid done > ???? DT/DTCFL/DTFS/DTINIT?? 0.635E-45?? 0.635E-45?? 0.000E+00?? 0.100E-02 > Step???? 61, t= 6.0800000E-02, DT= 8.0000000E-04, C=******* 2.2667E-01 > 1.8287E-02 > ???????????? Solving for fluid > > > ??? 3? ERROR:? Vanishing Jacobian near????? 2th node of element???????? 3. > > > ??? 2? ERROR:? Vanishing Jacobian near????? 2th node of element???????? 1. > ? 2.27348348709230109E+081 -5.12478988977734591E+080 > ?-2.60483379627720531E+079? 3.21465902039155941E+039 > ??? 3 xyz:? -5.30056E+39? -5.84642E+39 > ??? 3 xyz:? -5.24850E+39? -6.93109E+39 > > > ??? 3? ERROR:? Vanishing Jacobian near????? 2th node of element???????? 4. > ??? 2 xyz:?? 1.25061E+38?? 4.64957E+39 > ? 9.79493533554062390E+080 -3.01548938509156252E+080 > ??? 2 xyz:? -2.46589E-08? -5.64092E-01 > > > ??? 3 xyz:? -5.30056E+39? -5.84642E+39 > ??? 3 xyz:? -5.24850E+39? -6.93109E+39 > ??? 2? ERROR:? Vanishing Jacobian near????? 3th node of element???????? 2. > > > ??? 3? ERROR:? Vanishing Jacobian near????? 2th node of element???????? 5. > ? 1.43125817410005932E+039 -6.03607926692375119E+038 > ? 5.54918579647991880E+039 -1.67302572815141788E+039 > ??? 3 xyz:? -5.30056E+39? -5.84642E+39 > ??? 2 xyz:? -2.46589E-08? -5.64092E-01 > ??? 3 xyz:? -5.24850E+39? -6.93109E+39 > > > ??? 3? ERROR:? Vanishing Jacobian near????? 2th node of element???????? 6. > ??? 2 xyz:? -3.07794E-08? -7.04112E-01 > > > ??? 2? ERROR:? Vanishing Jacobian near????? 7th node of element???????? 7. > ? 8.35923896949543198E+038 -3.55455289325888722E+038 > ??? 3 xyz:? -5.30056E+39? -5.84642E+39 > ? 1.21747337192549314E+039 -1.79454406120891328E+038 > ??? 3 xyz:? -5.24850E+39? -6.93109E+39 > ??? 2 xyz:? -5.66434E-08? -1.29581E+00 > ??? 2 xyz:? -6.27639E-08? -1.43583E+00 > > > ??? 2? ERROR:? Vanishing Jacobian near????? 9th node of element???????? 8. > ? 1.17802538305091326E+039 -4.21489851051369387E+038 > ??? 2 xyz:? -6.55671E-08? -1.49996E+00 > ??? 2 xyz:? -3.25016E+38?? 4.93026E+39 > ?call outfld: ifpsco: F > > ?????? 61? 6.0800E-02 Write checkpoint: > > ?????? 61? 6.0800E-02 OPEN: > xyzcyl2.fld01 > ?Jac error 1, setting p66=4, ifxyo=t > > call exitt: dying ... > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Wed Feb 15 10:58:18 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 15 Feb 2012 11:58:18 -0500 Subject: [Nek5000-users] Vanishing Jacobians while using moving mesh In-Reply-To: References: Message-ID: Thanks Paul and Josh, I shall start by making the modification in the rea file and trying visit 2.3.2 Regards, Pradeep On Wed, Feb 15, 2012 at 9:39 AM, wrote: > Pradeep, > > Which version of Visit are you using? We have experienced similar > issues with version 2.4 when viewing 2D meshes. If this is the case, > try using 2.3.2 and see if you have the same problem. > > Josh > > On Tue, Feb 14, 2012 at 8:08 AM, wrote: > > Hi Neks, > > > > I'm trying to simulate 2D flow over an oscillating cylinder using moving > > mesh, and tried to set up a test case by looking at the peris example. I > > however am getting vanishing Jacobians after the first few timesteps. > > > > I am modifying the the boundary velocity of the cylinder in userbc > instead > > of userchk (as in the peris example). Would it be possible for you to > look > > at my .usr file and tell me what I am doing wrong? > > > > I have attached the .rea, .usr, and SIZE with this mail. > > > > Further, when I try to view the mesh of the output (or the xyz fld > > outputfile) in visit, visit crashes with the following error: > > VisIt's viewer exited abnormally! Aborting the Graphical User Interface. > > > > Lastly, would it be possible to simulate moving walls with large > > deformations (i.e. where multiple elements get deformed), where the > > deformation is known ahead of time? (eg. a flapping aerofoil) > > > > Thank you for your help! > > > > Regards, > > Pradeep > > > > Extract from logfile: > > > > 60 U-PRES gmres: 100 7.5345E+42 1.0000E-02 4.0062E+57 > > 6.7556E-03 1.5093E-02 > > ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 > > ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 > > ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 > > ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 > > 60 DNORM, DIVEX 1.18120867781751263E+043 > > 7.53448962619089522E+042 > > 60 6.0000E-02 1.6697E-02 Fluid done > > DT/DTCFL/DTFS/DTINIT 0.635E-45 0.635E-45 0.000E+00 0.100E-02 > > Step 61, t= 6.0800000E-02, DT= 8.0000000E-04, C=******* 2.2667E-01 > > 1.8287E-02 > > Solving for fluid > > > > > > 3 ERROR: Vanishing Jacobian near 2th node of element > 3. > > > > > > 2 ERROR: Vanishing Jacobian near 2th node of element > 1. > > 2.27348348709230109E+081 -5.12478988977734591E+080 > > -2.60483379627720531E+079 3.21465902039155941E+039 > > 3 xyz: -5.30056E+39 -5.84642E+39 > > 3 xyz: -5.24850E+39 -6.93109E+39 > > > > > > 3 ERROR: Vanishing Jacobian near 2th node of element > 4. > > 2 xyz: 1.25061E+38 4.64957E+39 > > 9.79493533554062390E+080 -3.01548938509156252E+080 > > 2 xyz: -2.46589E-08 -5.64092E-01 > > > > > > 3 xyz: -5.30056E+39 -5.84642E+39 > > 3 xyz: -5.24850E+39 -6.93109E+39 > > 2 ERROR: Vanishing Jacobian near 3th node of element > 2. > > > > > > 3 ERROR: Vanishing Jacobian near 2th node of element > 5. > > 1.43125817410005932E+039 -6.03607926692375119E+038 > > 5.54918579647991880E+039 -1.67302572815141788E+039 > > 3 xyz: -5.30056E+39 -5.84642E+39 > > 2 xyz: -2.46589E-08 -5.64092E-01 > > 3 xyz: -5.24850E+39 -6.93109E+39 > > > > > > 3 ERROR: Vanishing Jacobian near 2th node of element > 6. > > 2 xyz: -3.07794E-08 -7.04112E-01 > > > > > > 2 ERROR: Vanishing Jacobian near 7th node of element > 7. > > 8.35923896949543198E+038 -3.55455289325888722E+038 > > 3 xyz: -5.30056E+39 -5.84642E+39 > > 1.21747337192549314E+039 -1.79454406120891328E+038 > > 3 xyz: -5.24850E+39 -6.93109E+39 > > 2 xyz: -5.66434E-08 -1.29581E+00 > > 2 xyz: -6.27639E-08 -1.43583E+00 > > > > > > 2 ERROR: Vanishing Jacobian near 9th node of element > 8. > > 1.17802538305091326E+039 -4.21489851051369387E+038 > > 2 xyz: -6.55671E-08 -1.49996E+00 > > 2 xyz: -3.25016E+38 4.93026E+39 > > call outfld: ifpsco: F > > > > 61 6.0800E-02 Write checkpoint: > > > > 61 6.0800E-02 OPEN: > > xyzcyl2.fld01 > > Jac error 1, setting p66=4, ifxyo=t > > > > call exitt: dying ... > > > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > Nek5000-users mailing list > 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 Feb 16 02:10:11 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 09:10:11 +0100 Subject: [Nek5000-users] ON boundary condition In-Reply-To: References: <1329231757.21133.58.camel@skagsnebb.mech.kth.se> Message-ID: <1329379811.13757.21.camel@skagsnebb.mech.kth.se> Hi Paul Thank you for info. I'm using ON at the top of my box for jet in crossflow (it was originally in the setup I've got from Milos and I simply didn't change it) and it seem to work fine (I use Pn-Pn-2). My bigger problem is an outflow. I'm using O, but in many cases it gives reflections that trigger spurious oscillations, so I was looking for something better. To avoid this problem I run my simulations in the long box with an outflow 150 away from the pipe. It's a lot comparing to 60 in simson. Every run with the distance smaller than 100 gives nonphysical solutions. Is there in nekton some good non reflecting boundary condition? Best regards Adam On Wed, 2012-02-15 at 08:33 -0600, nek5000-users at lists.mcs.anl.gov wrote: > Hi Adam, > > I set up ON bc some years back to support Blasius boundary layer > analysis in which the tangential (streamwise) velocity is > prescribed and the wall-normal velocity is allowed to escape > as the velocity boundary layer thickens. This also implies > that the pressure is fixed on the upper surface. This feature > was developed for Pn-Pn-2 and hasn't been extensively tested > in many years. If this is a feature that you need, we could > look into resurrecting it. (Note that the "escaping" feature > implies that the surface is aligned with either x,y, or z, and > not inclined w.r.t. these principal axes.) > > Cheers, > > Paul > > > > On Tue, 14 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi all > > > > I try to find some information about ON boundary condition in nekton. > > What is the difference between O and ON? > > Regards > > > > Adam > > > > _______________________________________________ > > 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 Feb 16 04:15:24 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 04:15:24 -0600 (CST) Subject: [Nek5000-users] ON boundary condition In-Reply-To: <1329379811.13757.21.camel@skagsnebb.mech.kth.se> References: <1329231757.21133.58.camel@skagsnebb.mech.kth.se> <1329379811.13757.21.camel@skagsnebb.mech.kth.se> Message-ID: Hi Adam, What BC do you use for Simpson? Can you use the same for nek? I would assume some sort of sponge condition would be warranted. I personally like the div > 0 condition, which works well for turbulent outflow, but I've not tested it extensively for the issues that you are having. I'm guessing you might have more luck with the std. sponge approach. Please let me know if I can help, though I think that most of the sponge expertise is there in your lab. Best regards, Paul On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul > > Thank you for info. I'm using ON at the top of my box for jet in > crossflow (it was originally in the setup I've got from Milos and I > simply didn't change it) and it seem to work fine (I use Pn-Pn-2). My > bigger problem is an outflow. I'm using O, but in many cases it gives > reflections that trigger spurious oscillations, so I was looking for > something better. To avoid this problem I run my simulations in the long > box with an outflow 150 away from the pipe. It's a lot comparing to 60 > in simson. Every run with the distance smaller than 100 gives > nonphysical solutions. Is there in nekton some good non reflecting > boundary condition? > Best regards > > Adam > > On Wed, 2012-02-15 at 08:33 -0600, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Adam, >> >> I set up ON bc some years back to support Blasius boundary layer >> analysis in which the tangential (streamwise) velocity is >> prescribed and the wall-normal velocity is allowed to escape >> as the velocity boundary layer thickens. This also implies >> that the pressure is fixed on the upper surface. This feature >> was developed for Pn-Pn-2 and hasn't been extensively tested >> in many years. If this is a feature that you need, we could >> look into resurrecting it. (Note that the "escaping" feature >> implies that the surface is aligned with either x,y, or z, and >> not inclined w.r.t. these principal axes.) >> >> Cheers, >> >> Paul >> >> >> >> On Tue, 14 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi all >>> >>> I try to find some information about ON boundary condition in nekton. >>> What is the difference between O and ON? >>> Regards >>> >>> Adam >>> >>> _______________________________________________ >>> 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 Feb 16 04:43:00 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 11:43:00 +0100 Subject: [Nek5000-users] ON boundary condition In-Reply-To: References: <1329231757.21133.58.camel@skagsnebb.mech.kth.se> <1329379811.13757.21.camel@skagsnebb.mech.kth.se> Message-ID: <1329388980.14639.10.camel@skagsnebb.mech.kth.se> Hi Simpson is periodic in sreamwise direction so the fringe is needed. I will add fringe to my run and test dependence on the box size. Regards Adam On Thu, 2012-02-16 at 04:15 -0600, nek5000-users at lists.mcs.anl.gov wrote: > Hi Adam, > > What BC do you use for Simpson? Can you use the same for nek? > > I would assume some sort of sponge condition would be warranted. > I personally like the div > 0 condition, which works well for > turbulent outflow, but I've not tested it extensively for the > issues that you are having. I'm guessing you might have more > luck with the std. sponge approach. Please let me know if I > can help, though I think that most of the sponge expertise is > there in your lab. > > Best regards, > > Paul > > > On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Paul > > > > Thank you for info. I'm using ON at the top of my box for jet in > > crossflow (it was originally in the setup I've got from Milos and I > > simply didn't change it) and it seem to work fine (I use Pn-Pn-2). My > > bigger problem is an outflow. I'm using O, but in many cases it gives > > reflections that trigger spurious oscillations, so I was looking for > > something better. To avoid this problem I run my simulations in the long > > box with an outflow 150 away from the pipe. It's a lot comparing to 60 > > in simson. Every run with the distance smaller than 100 gives > > nonphysical solutions. Is there in nekton some good non reflecting > > boundary condition? > > Best regards > > > > Adam > > > > On Wed, 2012-02-15 at 08:33 -0600, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Adam, > >> > >> I set up ON bc some years back to support Blasius boundary layer > >> analysis in which the tangential (streamwise) velocity is > >> prescribed and the wall-normal velocity is allowed to escape > >> as the velocity boundary layer thickens. This also implies > >> that the pressure is fixed on the upper surface. This feature > >> was developed for Pn-Pn-2 and hasn't been extensively tested > >> in many years. If this is a feature that you need, we could > >> look into resurrecting it. (Note that the "escaping" feature > >> implies that the surface is aligned with either x,y, or z, and > >> not inclined w.r.t. these principal axes.) > >> > >> Cheers, > >> > >> Paul > >> > >> > >> > >> On Tue, 14 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hi all > >>> > >>> I try to find some information about ON boundary condition in nekton. > >>> What is the difference between O and ON? > >>> Regards > >>> > >>> Adam > >>> > >>> _______________________________________________ > >>> 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 Thu Feb 16 04:49:00 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 04:49:00 -0600 (CST) Subject: [Nek5000-users] ON boundary condition In-Reply-To: <1329388980.14639.10.camel@skagsnebb.mech.kth.se> References: <1329231757.21133.58.camel@skagsnebb.mech.kth.se> <1329379811.13757.21.camel@skagsnebb.mech.kth.se> <1329388980.14639.10.camel@skagsnebb.mech.kth.se> Message-ID: Hi Adam, Yes -- but you could of course run nek with periodicity in the streamwise direction, if that is what makes the difference. Paul On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi > > Simpson is periodic in sreamwise direction so the fringe is needed. I > will add fringe to my run and test dependence on the box size. > Regards > > Adam > > On Thu, 2012-02-16 at 04:15 -0600, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Adam, >> >> What BC do you use for Simpson? Can you use the same for nek? >> >> I would assume some sort of sponge condition would be warranted. >> I personally like the div > 0 condition, which works well for >> turbulent outflow, but I've not tested it extensively for the >> issues that you are having. I'm guessing you might have more >> luck with the std. sponge approach. Please let me know if I >> can help, though I think that most of the sponge expertise is >> there in your lab. >> >> Best regards, >> >> Paul >> >> >> On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Paul >>> >>> Thank you for info. I'm using ON at the top of my box for jet in >>> crossflow (it was originally in the setup I've got from Milos and I >>> simply didn't change it) and it seem to work fine (I use Pn-Pn-2). My >>> bigger problem is an outflow. I'm using O, but in many cases it gives >>> reflections that trigger spurious oscillations, so I was looking for >>> something better. To avoid this problem I run my simulations in the long >>> box with an outflow 150 away from the pipe. It's a lot comparing to 60 >>> in simson. Every run with the distance smaller than 100 gives >>> nonphysical solutions. Is there in nekton some good non reflecting >>> boundary condition? >>> Best regards >>> >>> Adam >>> >>> On Wed, 2012-02-15 at 08:33 -0600, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Hi Adam, >>>> >>>> I set up ON bc some years back to support Blasius boundary layer >>>> analysis in which the tangential (streamwise) velocity is >>>> prescribed and the wall-normal velocity is allowed to escape >>>> as the velocity boundary layer thickens. This also implies >>>> that the pressure is fixed on the upper surface. This feature >>>> was developed for Pn-Pn-2 and hasn't been extensively tested >>>> in many years. If this is a feature that you need, we could >>>> look into resurrecting it. (Note that the "escaping" feature >>>> implies that the surface is aligned with either x,y, or z, and >>>> not inclined w.r.t. these principal axes.) >>>> >>>> Cheers, >>>> >>>> Paul >>>> >>>> >>>> >>>> On Tue, 14 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> Hi all >>>>> >>>>> I try to find some information about ON boundary condition in nekton. >>>>> What is the difference between O and ON? >>>>> Regards >>>>> >>>>> Adam >>>>> >>>>> _______________________________________________ >>>>> 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 Thu Feb 16 05:22:49 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 12:22:49 +0100 Subject: [Nek5000-users] ON boundary condition In-Reply-To: References: <1329231757.21133.58.camel@skagsnebb.mech.kth.se> <1329379811.13757.21.camel@skagsnebb.mech.kth.se> <1329388980.14639.10.camel@skagsnebb.mech.kth.se> Message-ID: <1329391369.16322.18.camel@skagsnebb.mech.kth.se> Hi I did it to find the reason for the difference between simpson and nekton results. We found that special care has to be taken in both seups. Unfortunately this case seem to be extremely sensitive to any noise reflected from the walls or going through the fringe. I will test the non periodic case with the fringe. Thank you for help. Regards Adam On Thu, 2012-02-16 at 04:49 -0600, nek5000-users at lists.mcs.anl.gov wrote: > Hi Adam, > > Yes -- but you could of course run nek with periodicity in > the streamwise direction, if that is what makes the difference. > > Paul > > > > > On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi > > > > Simpson is periodic in sreamwise direction so the fringe is needed. I > > will add fringe to my run and test dependence on the box size. > > Regards > > > > Adam > > > > On Thu, 2012-02-16 at 04:15 -0600, nek5000-users at lists.mcs.anl.gov > > wrote: > >> Hi Adam, > >> > >> What BC do you use for Simpson? Can you use the same for nek? > >> > >> I would assume some sort of sponge condition would be warranted. > >> I personally like the div > 0 condition, which works well for > >> turbulent outflow, but I've not tested it extensively for the > >> issues that you are having. I'm guessing you might have more > >> luck with the std. sponge approach. Please let me know if I > >> can help, though I think that most of the sponge expertise is > >> there in your lab. > >> > >> Best regards, > >> > >> Paul > >> > >> > >> On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> Hi Paul > >>> > >>> Thank you for info. I'm using ON at the top of my box for jet in > >>> crossflow (it was originally in the setup I've got from Milos and I > >>> simply didn't change it) and it seem to work fine (I use Pn-Pn-2). My > >>> bigger problem is an outflow. I'm using O, but in many cases it gives > >>> reflections that trigger spurious oscillations, so I was looking for > >>> something better. To avoid this problem I run my simulations in the long > >>> box with an outflow 150 away from the pipe. It's a lot comparing to 60 > >>> in simson. Every run with the distance smaller than 100 gives > >>> nonphysical solutions. Is there in nekton some good non reflecting > >>> boundary condition? > >>> Best regards > >>> > >>> Adam > >>> > >>> On Wed, 2012-02-15 at 08:33 -0600, nek5000-users at lists.mcs.anl.gov > >>> wrote: > >>>> Hi Adam, > >>>> > >>>> I set up ON bc some years back to support Blasius boundary layer > >>>> analysis in which the tangential (streamwise) velocity is > >>>> prescribed and the wall-normal velocity is allowed to escape > >>>> as the velocity boundary layer thickens. This also implies > >>>> that the pressure is fixed on the upper surface. This feature > >>>> was developed for Pn-Pn-2 and hasn't been extensively tested > >>>> in many years. If this is a feature that you need, we could > >>>> look into resurrecting it. (Note that the "escaping" feature > >>>> implies that the surface is aligned with either x,y, or z, and > >>>> not inclined w.r.t. these principal axes.) > >>>> > >>>> Cheers, > >>>> > >>>> Paul > >>>> > >>>> > >>>> > >>>> On Tue, 14 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hi all > >>>>> > >>>>> I try to find some information about ON boundary condition in nekton. > >>>>> What is the difference between O and ON? > >>>>> Regards > >>>>> > >>>>> Adam > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Thu Feb 16 06:22:00 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 06:22:00 -0600 (CST) Subject: [Nek5000-users] Evaluate the validity of simulation results In-Reply-To: <977E8EBAA2E5E946A9311B0F429730FA7279E8F9D4@EXCHMBB.ornl.gov> References: <977E8EBAA2E5E946A9311B0F429730FA7279E8F9D4@EXCHMBB.ornl.gov> Message-ID: Hi Dong, I've been pondering this question for several days. Some errors might be catastrophic, some might just be annoying, and some might be totally benign. It often depends on the problem. 1) Examples of catastrophic include: .Altering the velocity field in a stability calculation .Altering a vector in the middle of a solver so that conjugate gradient perceives the operator or preconditioner as not being symmetric positive definite. 2) Examples of annoying include: .Altering the velocity field in a turbulence computation, where the flow field is changed but rapidly pulled back to its average behavior. 3) Examples of benign include: .Altering a vector mid-solver but not driving the result from the ball of convergence (i.e., the error recovers and contracts). The eddy problem is a good test case, given that we have an exact answer. It is not as sensitive as a stability computation (e.g., fs_hydro). Paul On Fri, 10 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi guys. > I am a computer science guy without any background in fluid dynamics solver. > I am using Nek5000 for the fault tolerance research. In particular, I inject > random errors into data structures of Nek5000 and then record how Nek5000 > reacts. Currently, I have a problem about how to judge the performance of > Nek5K with injected faults is normal (i.e., tolerating fault) or not. I can > simply record the execution time and then compare time difference. However, > some injected errors might not lead to time variance while making the > simulation result invalid. Is there any metric I can use to evaluate if the > simulation result is valid/reasonable (especially for the eddy and/or vortex > problem)? For example, a X error rate beyond a threshold after a fixed number > of timesteps, or something? > > Thank you very much. > > -Dong > > From nek5000-users at lists.mcs.anl.gov Thu Feb 16 06:26:05 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 06:26:05 -0600 (CST) Subject: [Nek5000-users] Vanishing Jacobians while using moving mesh In-Reply-To: References: Message-ID: Hi Pradeep, Attached is a case that appears to work. Hope this helps. Paul On Wed, 15 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Thanks Paul and Josh, > > I shall start by making the modification in the rea file and trying visit > 2.3.2 > > Regards, > Pradeep > > On Wed, Feb 15, 2012 at 9:39 AM, wrote: > >> Pradeep, >> >> Which version of Visit are you using? We have experienced similar >> issues with version 2.4 when viewing 2D meshes. If this is the case, >> try using 2.3.2 and see if you have the same problem. >> >> Josh >> >> On Tue, Feb 14, 2012 at 8:08 AM, wrote: >>> Hi Neks, >>> >>> I'm trying to simulate 2D flow over an oscillating cylinder using moving >>> mesh, and tried to set up a test case by looking at the peris example. I >>> however am getting vanishing Jacobians after the first few timesteps. >>> >>> I am modifying the the boundary velocity of the cylinder in userbc >> instead >>> of userchk (as in the peris example). Would it be possible for you to >> look >>> at my .usr file and tell me what I am doing wrong? >>> >>> I have attached the .rea, .usr, and SIZE with this mail. >>> >>> Further, when I try to view the mesh of the output (or the xyz fld >>> outputfile) in visit, visit crashes with the following error: >>> VisIt's viewer exited abnormally! Aborting the Graphical User Interface. >>> >>> Lastly, would it be possible to simulate moving walls with large >>> deformations (i.e. where multiple elements get deformed), where the >>> deformation is known ahead of time? (eg. a flapping aerofoil) >>> >>> Thank you for your help! >>> >>> Regards, >>> Pradeep >>> >>> Extract from logfile: >>> >>> 60 U-PRES gmres: 100 7.5345E+42 1.0000E-02 4.0062E+57 >>> 6.7556E-03 1.5093E-02 >>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>> 60 DNORM, DIVEX 1.18120867781751263E+043 >>> 7.53448962619089522E+042 >>> 60 6.0000E-02 1.6697E-02 Fluid done >>> DT/DTCFL/DTFS/DTINIT 0.635E-45 0.635E-45 0.000E+00 0.100E-02 >>> Step 61, t= 6.0800000E-02, DT= 8.0000000E-04, C=******* 2.2667E-01 >>> 1.8287E-02 >>> Solving for fluid >>> >>> >>> 3 ERROR: Vanishing Jacobian near 2th node of element >> 3. >>> >>> >>> 2 ERROR: Vanishing Jacobian near 2th node of element >> 1. >>> 2.27348348709230109E+081 -5.12478988977734591E+080 >>> -2.60483379627720531E+079 3.21465902039155941E+039 >>> 3 xyz: -5.30056E+39 -5.84642E+39 >>> 3 xyz: -5.24850E+39 -6.93109E+39 >>> >>> >>> 3 ERROR: Vanishing Jacobian near 2th node of element >> 4. >>> 2 xyz: 1.25061E+38 4.64957E+39 >>> 9.79493533554062390E+080 -3.01548938509156252E+080 >>> 2 xyz: -2.46589E-08 -5.64092E-01 >>> >>> >>> 3 xyz: -5.30056E+39 -5.84642E+39 >>> 3 xyz: -5.24850E+39 -6.93109E+39 >>> 2 ERROR: Vanishing Jacobian near 3th node of element >> 2. >>> >>> >>> 3 ERROR: Vanishing Jacobian near 2th node of element >> 5. >>> 1.43125817410005932E+039 -6.03607926692375119E+038 >>> 5.54918579647991880E+039 -1.67302572815141788E+039 >>> 3 xyz: -5.30056E+39 -5.84642E+39 >>> 2 xyz: -2.46589E-08 -5.64092E-01 >>> 3 xyz: -5.24850E+39 -6.93109E+39 >>> >>> >>> 3 ERROR: Vanishing Jacobian near 2th node of element >> 6. >>> 2 xyz: -3.07794E-08 -7.04112E-01 >>> >>> >>> 2 ERROR: Vanishing Jacobian near 7th node of element >> 7. >>> 8.35923896949543198E+038 -3.55455289325888722E+038 >>> 3 xyz: -5.30056E+39 -5.84642E+39 >>> 1.21747337192549314E+039 -1.79454406120891328E+038 >>> 3 xyz: -5.24850E+39 -6.93109E+39 >>> 2 xyz: -5.66434E-08 -1.29581E+00 >>> 2 xyz: -6.27639E-08 -1.43583E+00 >>> >>> >>> 2 ERROR: Vanishing Jacobian near 9th node of element >> 8. >>> 1.17802538305091326E+039 -4.21489851051369387E+038 >>> 2 xyz: -6.55671E-08 -1.49996E+00 >>> 2 xyz: -3.25016E+38 4.93026E+39 >>> call outfld: ifpsco: F >>> >>> 61 6.0800E-02 Write checkpoint: >>> >>> 61 6.0800E-02 OPEN: >>> xyzcyl2.fld01 >>> Jac error 1, setting p66=4, ifxyo=t >>> >>> call exitt: dying ... >>> >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> >> >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> _______________________________________________ >> Nek5000-users mailing list >> 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: t.tar.gz Type: application/octet-stream Size: 6346 bytes Desc: URL: From nek5000-users at lists.mcs.anl.gov Thu Feb 16 06:28:29 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 06:28:29 -0600 (CST) Subject: [Nek5000-users] Vanishing Jacobians while using moving mesh In-Reply-To: References: Message-ID: PS -- an example of the results can be found here: www.mcs.anl.gov/~fischer/ocyl.gif On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Pradeep, > > Attached is a case that appears to work. Hope this helps. > > Paul > > > On Wed, 15 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Thanks Paul and Josh, >> >> I shall start by making the modification in the rea file and trying visit >> 2.3.2 >> >> Regards, >> Pradeep >> >> On Wed, Feb 15, 2012 at 9:39 AM, wrote: >> >>> Pradeep, >>> >>> Which version of Visit are you using? We have experienced similar >>> issues with version 2.4 when viewing 2D meshes. If this is the case, >>> try using 2.3.2 and see if you have the same problem. >>> >>> Josh >>> >>> On Tue, Feb 14, 2012 at 8:08 AM, wrote: >>>> Hi Neks, >>>> >>>> I'm trying to simulate 2D flow over an oscillating cylinder using moving >>>> mesh, and tried to set up a test case by looking at the peris example. I >>>> however am getting vanishing Jacobians after the first few timesteps. >>>> >>>> I am modifying the the boundary velocity of the cylinder in userbc >>> instead >>>> of userchk (as in the peris example). Would it be possible for you to >>> look >>>> at my .usr file and tell me what I am doing wrong? >>>> >>>> I have attached the .rea, .usr, and SIZE with this mail. >>>> >>>> Further, when I try to view the mesh of the output (or the xyz fld >>>> outputfile) in visit, visit crashes with the following error: >>>> VisIt's viewer exited abnormally! Aborting the Graphical User Interface. >>>> >>>> Lastly, would it be possible to simulate moving walls with large >>>> deformations (i.e. where multiple elements get deformed), where the >>>> deformation is known ahead of time? (eg. a flapping aerofoil) >>>> >>>> Thank you for your help! >>>> >>>> Regards, >>>> Pradeep >>>> >>>> Extract from logfile: >>>> >>>> 60 U-PRES gmres: 100 7.5345E+42 1.0000E-02 4.0062E+57 >>>> 6.7556E-03 1.5093E-02 >>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>> 60 DNORM, DIVEX 1.18120867781751263E+043 >>>> 7.53448962619089522E+042 >>>> 60 6.0000E-02 1.6697E-02 Fluid done >>>> DT/DTCFL/DTFS/DTINIT 0.635E-45 0.635E-45 0.000E+00 0.100E-02 >>>> Step 61, t= 6.0800000E-02, DT= 8.0000000E-04, C=******* 2.2667E-01 >>>> 1.8287E-02 >>>> Solving for fluid >>>> >>>> >>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>> 3. >>>> >>>> >>>> 2 ERROR: Vanishing Jacobian near 2th node of element >>> 1. >>>> 2.27348348709230109E+081 -5.12478988977734591E+080 >>>> -2.60483379627720531E+079 3.21465902039155941E+039 >>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>> >>>> >>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>> 4. >>>> 2 xyz: 1.25061E+38 4.64957E+39 >>>> 9.79493533554062390E+080 -3.01548938509156252E+080 >>>> 2 xyz: -2.46589E-08 -5.64092E-01 >>>> >>>> >>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>> 2 ERROR: Vanishing Jacobian near 3th node of element >>> 2. >>>> >>>> >>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>> 5. >>>> 1.43125817410005932E+039 -6.03607926692375119E+038 >>>> 5.54918579647991880E+039 -1.67302572815141788E+039 >>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>> 2 xyz: -2.46589E-08 -5.64092E-01 >>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>> >>>> >>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>> 6. >>>> 2 xyz: -3.07794E-08 -7.04112E-01 >>>> >>>> >>>> 2 ERROR: Vanishing Jacobian near 7th node of element >>> 7. >>>> 8.35923896949543198E+038 -3.55455289325888722E+038 >>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>> 1.21747337192549314E+039 -1.79454406120891328E+038 >>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>> 2 xyz: -5.66434E-08 -1.29581E+00 >>>> 2 xyz: -6.27639E-08 -1.43583E+00 >>>> >>>> >>>> 2 ERROR: Vanishing Jacobian near 9th node of element >>> 8. >>>> 1.17802538305091326E+039 -4.21489851051369387E+038 >>>> 2 xyz: -6.55671E-08 -1.49996E+00 >>>> 2 xyz: -3.25016E+38 4.93026E+39 >>>> call outfld: ifpsco: F >>>> >>>> 61 6.0800E-02 Write checkpoint: >>>> >>>> 61 6.0800E-02 OPEN: >>>> xyzcyl2.fld01 >>>> Jac error 1, setting p66=4, ifxyo=t >>>> >>>> call exitt: dying ... >>>> >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>> >>> >>> >>> -- >>> Josh Camp >>> >>> "All that is necessary for the triumph of evil is that good men do >>> nothing" -- Edmund Burke >>> _______________________________________________ >>> Nek5000-users mailing list >>> 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 Feb 16 08:26:25 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 09:26:25 -0500 Subject: [Nek5000-users] Vanishing Jacobians while using moving mesh In-Reply-To: References: Message-ID: Hi Paul, Thank you so much for your help! Regards, Pradeep On Thu, Feb 16, 2012 at 7:28 AM, wrote: > > PS -- an example of the results can be found here: > > www.mcs.anl.gov/~fischer/ocyl.**gif > > > > > On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.**govwrote: > > >> Hi Pradeep, >> >> Attached is a case that appears to work. Hope this helps. >> >> Paul >> >> >> On Wed, 15 Feb 2012, nek5000-users at lists.mcs.anl.**govwrote: >> >> Thanks Paul and Josh, >>> >>> I shall start by making the modification in the rea file and trying visit >>> 2.3.2 >>> >>> Regards, >>> Pradeep >>> >>> On Wed, Feb 15, 2012 at 9:39 AM, > >>> wrote: >>> >>> Pradeep, >>>> >>>> Which version of Visit are you using? We have experienced similar >>>> issues with version 2.4 when viewing 2D meshes. If this is the case, >>>> try using 2.3.2 and see if you have the same problem. >>>> >>>> Josh >>>> >>>> On Tue, Feb 14, 2012 at 8:08 AM, > >>>> wrote: >>>> >>>>> Hi Neks, >>>>> >>>>> I'm trying to simulate 2D flow over an oscillating cylinder using >>>>> moving >>>>> mesh, and tried to set up a test case by looking at the peris example. >>>>> I >>>>> however am getting vanishing Jacobians after the first few timesteps. >>>>> >>>>> I am modifying the the boundary velocity of the cylinder in userbc >>>>> >>>> instead >>>> >>>>> of userchk (as in the peris example). Would it be possible for you to >>>>> >>>> look >>>> >>>>> at my .usr file and tell me what I am doing wrong? >>>>> >>>>> I have attached the .rea, .usr, and SIZE with this mail. >>>>> >>>>> Further, when I try to view the mesh of the output (or the xyz fld >>>>> outputfile) in visit, visit crashes with the following error: >>>>> VisIt's viewer exited abnormally! Aborting the Graphical User >>>>> Interface. >>>>> >>>>> Lastly, would it be possible to simulate moving walls with large >>>>> deformations (i.e. where multiple elements get deformed), where the >>>>> deformation is known ahead of time? (eg. a flapping aerofoil) >>>>> >>>>> Thank you for your help! >>>>> >>>>> Regards, >>>>> Pradeep >>>>> >>>>> Extract from logfile: >>>>> >>>>> 60 U-PRES gmres: 100 7.5345E+42 1.0000E-02 4.0062E+57 >>>>> 6.7556E-03 1.5093E-02 >>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>>> 60 DNORM, DIVEX 1.18120867781751263E+043 >>>>> 7.53448962619089522E+042 >>>>> 60 6.0000E-02 1.6697E-02 Fluid done >>>>> DT/DTCFL/DTFS/DTINIT 0.635E-45 0.635E-45 0.000E+00 >>>>> 0.100E-02 >>>>> Step 61, t= 6.0800000E-02, DT= 8.0000000E-04, C=******* 2.2667E-01 >>>>> 1.8287E-02 >>>>> Solving for fluid >>>>> >>>>> >>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>> >>>> 3. >>>> >>>>> >>>>> >>>>> 2 ERROR: Vanishing Jacobian near 2th node of element >>>>> >>>> 1. >>>> >>>>> 2.27348348709230109E+081 -5.12478988977734591E+080 >>>>> -2.60483379627720531E+079 3.21465902039155941E+039 >>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>> >>>>> >>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>> >>>> 4. >>>> >>>>> 2 xyz: 1.25061E+38 4.64957E+39 >>>>> 9.79493533554062390E+080 -3.01548938509156252E+080 >>>>> 2 xyz: -2.46589E-08 -5.64092E-01 >>>>> >>>>> >>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>> 2 ERROR: Vanishing Jacobian near 3th node of element >>>>> >>>> 2. >>>> >>>>> >>>>> >>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>> >>>> 5. >>>> >>>>> 1.43125817410005932E+039 -6.03607926692375119E+038 >>>>> 5.54918579647991880E+039 -1.67302572815141788E+039 >>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>> 2 xyz: -2.46589E-08 -5.64092E-01 >>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>> >>>>> >>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>> >>>> 6. >>>> >>>>> 2 xyz: -3.07794E-08 -7.04112E-01 >>>>> >>>>> >>>>> 2 ERROR: Vanishing Jacobian near 7th node of element >>>>> >>>> 7. >>>> >>>>> 8.35923896949543198E+038 -3.55455289325888722E+038 >>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>> 1.21747337192549314E+039 -1.79454406120891328E+038 >>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>> 2 xyz: -5.66434E-08 -1.29581E+00 >>>>> 2 xyz: -6.27639E-08 -1.43583E+00 >>>>> >>>>> >>>>> 2 ERROR: Vanishing Jacobian near 9th node of element >>>>> >>>> 8. >>>> >>>>> 1.17802538305091326E+039 -4.21489851051369387E+038 >>>>> 2 xyz: -6.55671E-08 -1.49996E+00 >>>>> 2 xyz: -3.25016E+38 4.93026E+39 >>>>> call outfld: ifpsco: F >>>>> >>>>> 61 6.0800E-02 Write checkpoint: >>>>> >>>>> 61 6.0800E-02 OPEN: >>>>> xyzcyl2.fld01 >>>>> Jac error 1, setting p66=4, ifxyo=t >>>>> >>>>> call exitt: dying ... >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.**gov >>>>> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >>>>> >>>>> >>>> >>>> >>>> -- >>>> Josh Camp >>>> >>>> "All that is necessary for the triumph of evil is that good men do >>>> nothing" -- Edmund Burke >>>> ______________________________**_________________ >>>> Nek5000-users mailing list >>>> 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 Feb 16 16:26:14 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Feb 2012 17:26:14 -0500 Subject: [Nek5000-users] Evaluate the validity of simulation results In-Reply-To: References: <977E8EBAA2E5E946A9311B0F429730FA7279E8F9D4@EXCHMBB.ornl.gov> Message-ID: <977E8EBAA2E5E946A9311B0F429730FA7279E8F9E2@EXCHMBB.ornl.gov> Thank you very much for your detailed answers, Paul. -Dong -----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: Thursday, February 16, 2012 7:22 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Evaluate the validity of simulation results Hi Dong, I've been pondering this question for several days. Some errors might be catastrophic, some might just be annoying, and some might be totally benign. It often depends on the problem. 1) Examples of catastrophic include: .Altering the velocity field in a stability calculation .Altering a vector in the middle of a solver so that conjugate gradient perceives the operator or preconditioner as not being symmetric positive definite. 2) Examples of annoying include: .Altering the velocity field in a turbulence computation, where the flow field is changed but rapidly pulled back to its average behavior. 3) Examples of benign include: .Altering a vector mid-solver but not driving the result from the ball of convergence (i.e., the error recovers and contracts). The eddy problem is a good test case, given that we have an exact answer. It is not as sensitive as a stability computation (e.g., fs_hydro). Paul On Fri, 10 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi guys. > I am a computer science guy without any background in fluid dynamics solver. > I am using Nek5000 for the fault tolerance research. In particular, I inject > random errors into data structures of Nek5000 and then record how Nek5000 > reacts. Currently, I have a problem about how to judge the performance of > Nek5K with injected faults is normal (i.e., tolerating fault) or not. I can > simply record the execution time and then compare time difference. However, > some injected errors might not lead to time variance while making the > simulation result invalid. Is there any metric I can use to evaluate if the > simulation result is valid/reasonable (especially for the eddy and/or vortex > problem)? For example, a X error rate beyond a threshold after a fixed number > of timesteps, or something? > > Thank you very much. > > -Dong > > _______________________________________________ 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 Feb 21 06:13:34 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 21 Feb 2012 06:13:34 -0600 (CST) Subject: [Nek5000-users] Vanishing Jacobians while using moving mesh In-Reply-To: References: Message-ID: Hi Pradeep, There was one thing that I'd intended to mention regarding mesh motion. The file that I set up uses the most general ALE formulation, where the mesh velocity is computed through an elasticity solver. The performance for this solver has not been optimized, but there are several tricks we can use to make it faster. At the moment, I would guess that well over half the time is spent in this solver, which could be an issue if you plan to look at 3D problems. As you get into production runs we should examine the performance and optimize if necessary. Regards, Paul On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thank you so much for your help! > > Regards, > Pradeep > > On Thu, Feb 16, 2012 at 7:28 AM, wrote: > >> >> PS -- an example of the results can be found here: >> >> www.mcs.anl.gov/~fischer/ocyl.**gif >> >> >> >> >> On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.**govwrote: >> >> >>> Hi Pradeep, >>> >>> Attached is a case that appears to work. Hope this helps. >>> >>> Paul >>> >>> >>> On Wed, 15 Feb 2012, nek5000-users at lists.mcs.anl.**govwrote: >>> >>> Thanks Paul and Josh, >>>> >>>> I shall start by making the modification in the rea file and trying visit >>>> 2.3.2 >>>> >>>> Regards, >>>> Pradeep >>>> >>>> On Wed, Feb 15, 2012 at 9:39 AM, > >>>> wrote: >>>> >>>> Pradeep, >>>>> >>>>> Which version of Visit are you using? We have experienced similar >>>>> issues with version 2.4 when viewing 2D meshes. If this is the case, >>>>> try using 2.3.2 and see if you have the same problem. >>>>> >>>>> Josh >>>>> >>>>> On Tue, Feb 14, 2012 at 8:08 AM, > >>>>> wrote: >>>>> >>>>>> Hi Neks, >>>>>> >>>>>> I'm trying to simulate 2D flow over an oscillating cylinder using >>>>>> moving >>>>>> mesh, and tried to set up a test case by looking at the peris example. >>>>>> I >>>>>> however am getting vanishing Jacobians after the first few timesteps. >>>>>> >>>>>> I am modifying the the boundary velocity of the cylinder in userbc >>>>>> >>>>> instead >>>>> >>>>>> of userchk (as in the peris example). Would it be possible for you to >>>>>> >>>>> look >>>>> >>>>>> at my .usr file and tell me what I am doing wrong? >>>>>> >>>>>> I have attached the .rea, .usr, and SIZE with this mail. >>>>>> >>>>>> Further, when I try to view the mesh of the output (or the xyz fld >>>>>> outputfile) in visit, visit crashes with the following error: >>>>>> VisIt's viewer exited abnormally! Aborting the Graphical User >>>>>> Interface. >>>>>> >>>>>> Lastly, would it be possible to simulate moving walls with large >>>>>> deformations (i.e. where multiple elements get deformed), where the >>>>>> deformation is known ahead of time? (eg. a flapping aerofoil) >>>>>> >>>>>> Thank you for your help! >>>>>> >>>>>> Regards, >>>>>> Pradeep >>>>>> >>>>>> Extract from logfile: >>>>>> >>>>>> 60 U-PRES gmres: 100 7.5345E+42 1.0000E-02 4.0062E+57 >>>>>> 6.7556E-03 1.5093E-02 >>>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 16 >>>>>> 60 DNORM, DIVEX 1.18120867781751263E+043 >>>>>> 7.53448962619089522E+042 >>>>>> 60 6.0000E-02 1.6697E-02 Fluid done >>>>>> DT/DTCFL/DTFS/DTINIT 0.635E-45 0.635E-45 0.000E+00 >>>>>> 0.100E-02 >>>>>> Step 61, t= 6.0800000E-02, DT= 8.0000000E-04, C=******* 2.2667E-01 >>>>>> 1.8287E-02 >>>>>> Solving for fluid >>>>>> >>>>>> >>>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>>> >>>>> 3. >>>>> >>>>>> >>>>>> >>>>>> 2 ERROR: Vanishing Jacobian near 2th node of element >>>>>> >>>>> 1. >>>>> >>>>>> 2.27348348709230109E+081 -5.12478988977734591E+080 >>>>>> -2.60483379627720531E+079 3.21465902039155941E+039 >>>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>>> >>>>>> >>>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>>> >>>>> 4. >>>>> >>>>>> 2 xyz: 1.25061E+38 4.64957E+39 >>>>>> 9.79493533554062390E+080 -3.01548938509156252E+080 >>>>>> 2 xyz: -2.46589E-08 -5.64092E-01 >>>>>> >>>>>> >>>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>>> 2 ERROR: Vanishing Jacobian near 3th node of element >>>>>> >>>>> 2. >>>>> >>>>>> >>>>>> >>>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>>> >>>>> 5. >>>>> >>>>>> 1.43125817410005932E+039 -6.03607926692375119E+038 >>>>>> 5.54918579647991880E+039 -1.67302572815141788E+039 >>>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>>> 2 xyz: -2.46589E-08 -5.64092E-01 >>>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>>> >>>>>> >>>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>>> >>>>> 6. >>>>> >>>>>> 2 xyz: -3.07794E-08 -7.04112E-01 >>>>>> >>>>>> >>>>>> 2 ERROR: Vanishing Jacobian near 7th node of element >>>>>> >>>>> 7. >>>>> >>>>>> 8.35923896949543198E+038 -3.55455289325888722E+038 >>>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>>> 1.21747337192549314E+039 -1.79454406120891328E+038 >>>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>>> 2 xyz: -5.66434E-08 -1.29581E+00 >>>>>> 2 xyz: -6.27639E-08 -1.43583E+00 >>>>>> >>>>>> >>>>>> 2 ERROR: Vanishing Jacobian near 9th node of element >>>>>> >>>>> 8. >>>>> >>>>>> 1.17802538305091326E+039 -4.21489851051369387E+038 >>>>>> 2 xyz: -6.55671E-08 -1.49996E+00 >>>>>> 2 xyz: -3.25016E+38 4.93026E+39 >>>>>> call outfld: ifpsco: F >>>>>> >>>>>> 61 6.0800E-02 Write checkpoint: >>>>>> >>>>>> 61 6.0800E-02 OPEN: >>>>>> xyzcyl2.fld01 >>>>>> Jac error 1, setting p66=4, ifxyo=t >>>>>> >>>>>> call exitt: dying ... >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> Nek5000-users mailing list >>>>>> Nek5000-users at lists.mcs.anl.**gov >>>>>> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Josh Camp >>>>> >>>>> "All that is necessary for the triumph of evil is that good men do >>>>> nothing" -- Edmund Burke >>>>> ______________________________**_________________ >>>>> Nek5000-users mailing list >>>>> 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 Tue Feb 21 11:32:41 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 21 Feb 2012 18:32:41 +0100 Subject: [Nek5000-users] pressure normalisation in periodic flows Message-ID: <015a01ccf0be$d375b1a0$7a6114e0$@mech.kth.se> Dear all, We are running turbulent pipe flow. During these runs we have observed some interesting behaviour of the instantaneous pressure, namely its mean value can be of order 10e7 depending on the run. We have tried various ways to bring that mean instantaneous pressure down to around zero, but we only succeeded partially. Of course, for computing the flow statistics (such as

and prms) we do have an additional normalisation based on the mean wall pressure, but having such a high "computational" pressure may lead to loss of precision which we would like to avoid. Therefore, we have a few questions which we tried to figure out during the last weeks: 1) from the Deville, Fischer and Mund book (and previous channel experiences) we assume that nek5000 will in the case of periodic bc (that is without any "O" condition) set the mean instantaneous pressure to zero. For some of our runs this is most probably fulfilled (checked only graphically...). Which routine would you suggest to use to do a volume average of the pressure (pnpn-2)? 2) Some of our runs were initially ran using the older restart scheme with only a single field/single precision. Since a few weeks we are exclusively using the newer restart option with four previous fields/double precision. The runs that were originally run with the old restart option are the ones that experience the high pressure values, whereas the cases that were only run (i.e. from the initiation with random noise) with the new restart have "correct" pressure levels (i.e. around zero). We would like to reduce the high pressures from the older runs. We have tried many things; subtracting a mean pressure in userchk, removing the wall pressure during the run etc., but none of these options completely solved our issue (i.e. the pressure was rising again). Would there be an option to restart nek without specifying a pressure? 3) To learn more about how nek is really doing the normalisation, which part of the code is doing the p-normalisation? By the way, we are using PnPn-2, mainly because our experience is that we are faster for our case. Thanks a lot for any help! Philipp From nek5000-users at lists.mcs.anl.gov Tue Feb 21 11:55:10 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 21 Feb 2012 11:55:10 -0600 (CST) Subject: [Nek5000-users] pressure normalisation in periodic flows In-Reply-To: <015a01ccf0be$d375b1a0$7a6114e0$@mech.kth.se> References: <015a01ccf0be$d375b1a0$7a6114e0$@mech.kth.se> Message-ID: Dear Philipp, Thank you for the detailed note. The normal way to orthogonalize would be: call ortho(pr) One has to be careful in this context since there are two types of orthogonalization to consider. One is where you remove the kernel of the pressure matrix (i.e., the vector of all 1's), the other is where you remove the physical mean. These values are defined as follows: pbar_alg = sum_i=1,n (p_i) / n pbar_phy = int p dV / volume Currently, ortho() does the former, since that is the condition we are trying to satisfy in the iterative solvers. Which condition is best for you is not 100% clear to me, but it is probably a fine point that is not of leading-order importance. In any case, you can evaluate these as follows: include 'SIZE' include 'TOTAL' integer*8 ntotpg ! Possibly more than 2 billion pts total ntotp = nelv*nx2*ny2*nz2 ntotpg = ntotp ntotpg = i8glsum(ntotpg,1) ! Input must be integer*8 pbar_alg = glsum(pr,ntotp)/ntotpg pbar_phy = glsc2(pr,bm2,ntotp)/volvm2 What is more curious is, why is the pressure spiking? If you have a repeatable case where this happens, I'd be happy to dig into it. Please feel free to contact me off-list if you'd like to transfer some files. I'm happy to hear that the new restart feature avoids this problem. Best regards, Paul On Tue, 21 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Dear all, > We are running turbulent pipe flow. During these runs we have observed some > interesting behaviour of the instantaneous pressure, namely its mean value > can be of order 10e7 depending on the run. We have tried various ways to > bring that mean instantaneous pressure down to around zero, but we only > succeeded partially. Of course, for computing the flow statistics (such as >

and prms) we do have an additional normalisation based on the mean wall > pressure, but having such a high "computational" pressure may lead to loss > of precision which we would like to avoid. > > Therefore, we have a few questions which we tried to figure out during the > last weeks: > 1) from the Deville, Fischer and Mund book (and previous channel > experiences) we assume that nek5000 will in the case of periodic bc (that is > without any "O" condition) set the mean instantaneous pressure to zero. For > some of our runs this is most probably fulfilled (checked only > graphically...). Which routine would you suggest to use to do a volume > average of the pressure (pnpn-2)? > 2) Some of our runs were initially ran using the older restart scheme with > only a single field/single precision. Since a few weeks we are exclusively > using the newer restart option with four previous fields/double precision. > The runs that were originally run with the old restart option are the ones > that experience the high pressure values, whereas the cases that were only > run (i.e. from the initiation with random noise) with the new restart have > "correct" pressure levels (i.e. around zero). > We would like to reduce the high pressures from the older runs. We have > tried many things; subtracting a mean pressure in userchk, removing the wall > pressure during the run etc., but none of these options completely solved > our issue (i.e. the pressure was rising again). Would there be an option to > restart nek without specifying a pressure? > 3) To learn more about how nek is really doing the normalisation, which part > of the code is doing the p-normalisation? > > By the way, we are using PnPn-2, mainly because our experience is that we > are faster for our case. > > Thanks a lot for any help! > Philipp > > _______________________________________________ > 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 Feb 22 11:08:57 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 22 Feb 2012 10:08:57 -0700 Subject: [Nek5000-users] rotational symmetry Message-ID: Hello Neks. I'm simulating rotating flow in a cylindrical geometry via a Coriolis forcing. Is there any periodic-BC mechanism for exploiting the symmetry, or do I need to model the whole thing? Thanks. --Mike From nek5000-users at lists.mcs.anl.gov Fri Feb 24 10:55:49 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 24 Feb 2012 09:55:49 -0700 Subject: [Nek5000-users] nek hangup in parallel Message-ID: Hello All. I have a question regarding an observation that I have made several times with nek in parallel over several nodes. In short, it's this: Say I have a nek run (that works fine but slow in serial): -- If I compile and run it via mpif77/mpicc on 8 cores over ONE node, it runs fine. -- If I run it over 8 cores over TWO nodes (4-cores per node), it runs fine. -- If I run it on 16 cores over TWO nodes, it gets hung up; here is an example of what I see at the end of the log file of the hung job: gs_setup: 47118 unique labels shared pairwise times (avg, min, max): 0.369331 0.344326 0.39997 crystal router : 0.297755 0.279986 0.319981 all reduce : 3.00363 2.98819 3.02431 used all_to_all method: crystal router setupds time 5.5196E+01 seconds 4 6 358599 5448 setup h1 coarse grid, nx_crs= 2 call usrsetvert done :: usrsetvert gs_setup: 1962 unique labels shared pairwise times (avg, min, max): 0.0988146 0.0853947 0.103889 crystal router : 0.200801 0.187893 0.208487 all reduce : 1.1251 1.11958 1.13993 used all_to_all method: pairwise I've notified our cluster-admin group about this to see if they can isolate a local problem, but I wanted to ask the nek community (aka you guys) if anyone has seen something similar. Thanks. --Mike From nek5000-users at lists.mcs.anl.gov Fri Feb 24 11:04:39 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 24 Feb 2012 11:04:39 -0600 (CST) Subject: [Nek5000-users] nek hangup in parallel In-Reply-To: References: Message-ID: Hi Mike, Sorry that it's hanging for you. I don't know of a general hang-up since we routinely run at these levels and beyond. If you want to send the case off-list, we can try it on our linux cluster. Paul On Fri, 24 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hello All. > > I have a question regarding an observation that I have made several times with nek in parallel over several nodes. In short, it's this: > > Say I have a nek run (that works fine but slow in serial): > -- If I compile and run it via mpif77/mpicc on 8 cores over ONE node, it runs fine. > -- If I run it over 8 cores over TWO nodes (4-cores per node), it runs fine. > -- If I run it on 16 cores over TWO nodes, it gets hung up; here is an example of what I see at the end of the log file of the hung job: > > gs_setup: 47118 unique labels shared > pairwise times (avg, min, max): 0.369331 0.344326 0.39997 > crystal router : 0.297755 0.279986 0.319981 > all reduce : 3.00363 2.98819 3.02431 > used all_to_all method: crystal router > setupds time 5.5196E+01 seconds 4 6 358599 5448 > setup h1 coarse grid, nx_crs= 2 > call usrsetvert > done :: usrsetvert > > gs_setup: 1962 unique labels shared > pairwise times (avg, min, max): 0.0988146 0.0853947 0.103889 > crystal router : 0.200801 0.187893 0.208487 > all reduce : 1.1251 1.11958 1.13993 > used all_to_all method: pairwise > > I've notified our cluster-admin group about this to see if they can isolate a local problem, but I wanted to ask the nek community (aka you guys) if anyone has seen something similar. > > Thanks. > --Mike > > _______________________________________________ > 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 Feb 24 12:18:46 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 24 Feb 2012 19:18:46 +0100 Subject: [Nek5000-users] pressure normalisation in periodic flows In-Reply-To: References: <015a01ccf0be$d375b1a0$7a6114e0$@mech.kth.se> Message-ID: <20120224191846.12863adifwecvlvq@www.mech.kth.se> Dear Paul, Thank you for your reply. In regards to the pressure normalization we have tested the following: 1- Starting from restart files containing the high-pressure values (of order 10^7). A run was performed for 53 time-steps and in the USERCHK, we have normalized the pressure as follows: ---------------------------------------------------------------------------- C%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%C common /scrcg/ pm1(lx1,ly1,lz1,lelv) ! Mapped pressure real pa(lx1,ly1,lz1), pb(lx1,ly1,lz1) ! Working arrays for mapp integer*8 ntotpg ! Possibly more than 2 billion pts total C%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%C call my_full_restart ! save/load files for full-restart ntotp = nelv*nx2*ny2*nz2 ntotpg = ntotp ntotpg = i8glsum(ntotpg,1) ! Input must be integer*8 pbar_alg = glsum(pr,ntotp)/ntotpg pbar_phy = -glsc2(pr,bm2,ntotp)/volvm2 call cadd(pr,pbar_phy,ntotp) ---------------------------------------------------------------------------- After the run ended, the pressure values were around zeros. For several runs after-wards with the above procedure in the USERCHK taken away. The pressure was fine and it didn't spike again. Meanwhile: 2- Starting from the same set of files (containing the high-pressure values). A run was performed for 153 time-steps with no pressure normalization in the USERCHK as before. Here, we looked at the subroutine ortho (respr) in navier1.f and printed out the values of respr,rlam. These were of order 1E-07 and E-012. However, during the run the pressure was high, and this was noticed by printing out (pr) in the USERCHK where the values were of order 10^7. Best regards George Quoting nek5000-users at lists.mcs.anl.gov: > > Dear Philipp, > > Thank you for the detailed note. > > The normal way to orthogonalize would be: > > call ortho(pr) > > One has to be careful in this context since there are two > types of orthogonalization to consider. One is where you > remove the kernel of the pressure matrix (i.e., the vector > of all 1's), the other is where you remove the physical > mean. These values are defined as follows: > > pbar_alg = sum_i=1,n (p_i) / n > > pbar_phy = int p dV / volume > > Currently, ortho() does the former, since that is the > condition we are trying to satisfy in the iterative solvers. > Which condition is best for you is not 100% clear to me, but > it is probably a fine point that is not of leading-order > importance. In any case, you can evaluate these as follows: > > include 'SIZE' > include 'TOTAL' > > integer*8 ntotpg ! Possibly more than 2 billion pts total > > ntotp = nelv*nx2*ny2*nz2 > ntotpg = ntotp > ntotpg = i8glsum(ntotpg,1) ! Input must be integer*8 > pbar_alg = glsum(pr,ntotp)/ntotpg > > pbar_phy = glsc2(pr,bm2,ntotp)/volvm2 > > What is more curious is, why is the pressure spiking? > If you have a repeatable case where this happens, I'd > be happy to dig into it. Please feel free to contact > me off-list if you'd like to transfer some files. > > I'm happy to hear that the new restart feature avoids > this problem. > > Best regards, > > Paul > > > > > On Tue, 21 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear all, >> We are running turbulent pipe flow. During these runs we have observed some >> interesting behaviour of the instantaneous pressure, namely its mean value >> can be of order 10e7 depending on the run. We have tried various ways to >> bring that mean instantaneous pressure down to around zero, but we only >> succeeded partially. Of course, for computing the flow statistics (such as >>

and prms) we do have an additional normalisation based on the mean wall >> pressure, but having such a high "computational" pressure may lead to loss >> of precision which we would like to avoid. >> >> Therefore, we have a few questions which we tried to figure out during the >> last weeks: >> 1) from the Deville, Fischer and Mund book (and previous channel >> experiences) we assume that nek5000 will in the case of periodic bc (that is >> without any "O" condition) set the mean instantaneous pressure to zero. For >> some of our runs this is most probably fulfilled (checked only >> graphically...). Which routine would you suggest to use to do a volume >> average of the pressure (pnpn-2)? >> 2) Some of our runs were initially ran using the older restart scheme with >> only a single field/single precision. Since a few weeks we are exclusively >> using the newer restart option with four previous fields/double precision. >> The runs that were originally run with the old restart option are the ones >> that experience the high pressure values, whereas the cases that were only >> run (i.e. from the initiation with random noise) with the new restart have >> "correct" pressure levels (i.e. around zero). >> We would like to reduce the high pressures from the older runs. We have >> tried many things; subtracting a mean pressure in userchk, removing the wall >> pressure during the run etc., but none of these options completely solved >> our issue (i.e. the pressure was rising again). Would there be an option to >> restart nek without specifying a pressure? >> 3) To learn more about how nek is really doing the normalisation, which part >> of the code is doing the p-normalisation? >> >> By the way, we are using PnPn-2, mainly because our experience is that we >> are faster for our case. >> >> Thanks a lot for any help! >> Philipp >> >> _______________________________________________ >> 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 > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From nek5000-users at lists.mcs.anl.gov Fri Feb 24 12:42:21 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 24 Feb 2012 12:42:21 -0600 (CST) Subject: [Nek5000-users] pressure normalisation in periodic flows In-Reply-To: <20120224191846.12863adifwecvlvq@www.mech.kth.se> References: <015a01ccf0be$d375b1a0$7a6114e0$@mech.kth.se> <20120224191846.12863adifwecvlvq@www.mech.kth.se> Message-ID: Dear Philipp, Thank you for your email. I think I understand the issue... Without yet verifying it, my guess is that we never explicitly orthogonalize p itself, but only dp and thus if there is somehow drift in the mean of p it is not corrected. At this point, this is just a hypothesis... I'll try to verify. Best regards, Paul On Fri, 24 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > > Dear Paul, > > Thank you for your reply. In regards to the pressure normalization we > have tested the following: > > 1- Starting from restart files containing the high-pressure values (of > order 10^7). A run was performed for 53 time-steps and in the USERCHK, > we have normalized the pressure as follows: > > ---------------------------------------------------------------------------- > > C%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%C > common /scrcg/ pm1(lx1,ly1,lz1,lelv) ! Mapped pressure > real pa(lx1,ly1,lz1), pb(lx1,ly1,lz1) ! Working arrays for mapp > integer*8 ntotpg ! Possibly more than 2 billion pts total > C%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%C > > call my_full_restart ! save/load files for full-restart > > ntotp = nelv*nx2*ny2*nz2 > ntotpg = ntotp > ntotpg = i8glsum(ntotpg,1) ! Input must be integer*8 > pbar_alg = glsum(pr,ntotp)/ntotpg > pbar_phy = -glsc2(pr,bm2,ntotp)/volvm2 > call cadd(pr,pbar_phy,ntotp) > > ---------------------------------------------------------------------------- > > After the run ended, the pressure values were around zeros. For > several runs after-wards with the above procedure in the USERCHK taken > away. The pressure was fine and it didn't spike again. > > Meanwhile: > > 2- Starting from the same set of files (containing the high-pressure > values). A run was performed for 153 time-steps with no pressure > normalization in the USERCHK as before. Here, we looked at the > > subroutine ortho (respr) > > in navier1.f and printed out the values of respr,rlam. These were of order > 1E-07 and E-012. However, during the run the pressure was high, and this was > noticed by printing out (pr) in the USERCHK where the values were of order > 10^7. > > Best regards > > George > > > Quoting nek5000-users at lists.mcs.anl.gov: > >> >> Dear Philipp, >> >> Thank you for the detailed note. >> >> The normal way to orthogonalize would be: >> >> call ortho(pr) >> >> One has to be careful in this context since there are two >> types of orthogonalization to consider. One is where you >> remove the kernel of the pressure matrix (i.e., the vector >> of all 1's), the other is where you remove the physical >> mean. These values are defined as follows: >> >> pbar_alg = sum_i=1,n (p_i) / n >> >> pbar_phy = int p dV / volume >> >> Currently, ortho() does the former, since that is the >> condition we are trying to satisfy in the iterative solvers. >> Which condition is best for you is not 100% clear to me, but >> it is probably a fine point that is not of leading-order >> importance. In any case, you can evaluate these as follows: >> >> include 'SIZE' >> include 'TOTAL' >> >> integer*8 ntotpg ! Possibly more than 2 billion pts total >> >> ntotp = nelv*nx2*ny2*nz2 >> ntotpg = ntotp >> ntotpg = i8glsum(ntotpg,1) ! Input must be integer*8 >> pbar_alg = glsum(pr,ntotp)/ntotpg >> >> pbar_phy = glsc2(pr,bm2,ntotp)/volvm2 >> >> What is more curious is, why is the pressure spiking? >> If you have a repeatable case where this happens, I'd >> be happy to dig into it. Please feel free to contact >> me off-list if you'd like to transfer some files. >> >> I'm happy to hear that the new restart feature avoids >> this problem. >> >> Best regards, >> >> Paul >> >> >> >> >> On Tue, 21 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear all, >>> We are running turbulent pipe flow. During these runs we have observed >>> some >>> interesting behaviour of the instantaneous pressure, namely its mean value >>> can be of order 10e7 depending on the run. We have tried various ways to >>> bring that mean instantaneous pressure down to around zero, but we only >>> succeeded partially. Of course, for computing the flow statistics (such as >>>

and prms) we do have an additional normalisation based on the mean >>> wall >>> pressure, but having such a high "computational" pressure may lead to loss >>> of precision which we would like to avoid. >>> >>> Therefore, we have a few questions which we tried to figure out during the >>> last weeks: >>> 1) from the Deville, Fischer and Mund book (and previous channel >>> experiences) we assume that nek5000 will in the case of periodic bc (that >>> is >>> without any "O" condition) set the mean instantaneous pressure to zero. >>> For >>> some of our runs this is most probably fulfilled (checked only >>> graphically...). Which routine would you suggest to use to do a volume >>> average of the pressure (pnpn-2)? >>> 2) Some of our runs were initially ran using the older restart scheme with >>> only a single field/single precision. Since a few weeks we are exclusively >>> using the newer restart option with four previous fields/double precision. >>> The runs that were originally run with the old restart option are the ones >>> that experience the high pressure values, whereas the cases that were only >>> run (i.e. from the initiation with random noise) with the new restart have >>> "correct" pressure levels (i.e. around zero). >>> We would like to reduce the high pressures from the older runs. We have >>> tried many things; subtracting a mean pressure in userchk, removing the >>> wall >>> pressure during the run etc., but none of these options completely solved >>> our issue (i.e. the pressure was rising again). Would there be an option >>> to >>> restart nek without specifying a pressure? >>> 3) To learn more about how nek is really doing the normalisation, which >>> part >>> of the code is doing the p-normalisation? >>> >>> By the way, we are using PnPn-2, mainly because our experience is that we >>> are faster for our case. >>> >>> Thanks a lot for any help! >>> Philipp >>> >>> _______________________________________________ >>> 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 >> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > _______________________________________________ > 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 Feb 27 10:23:47 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 27 Feb 2012 11:23:47 -0500 Subject: [Nek5000-users] Vanishing Jacobians while using moving mesh In-Reply-To: References: Message-ID: Hi Paul, Sorry for the late reply. That would be great. I will get back once I start with 3D runs. Regards, Pradeep On Tue, Feb 21, 2012 at 7:13 AM, wrote: > > Hi Pradeep, > > There was one thing that I'd intended to mention regarding mesh motion. > > The file that I set up uses the most general ALE formulation, > where the mesh velocity is computed through an elasticity solver. > The performance for this solver has not been optimized, but there > are several tricks we can use to make it faster. At the moment, > I would guess that well over half the time is spent in this solver, > which could be an issue if you plan to look at 3D problems. As > you get into production runs we should examine the performance and > optimize if necessary. > > Regards, > > Paul > > > > On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.**govwrote: > > Hi Paul, >> >> Thank you so much for your help! >> >> Regards, >> Pradeep >> >> On Thu, Feb 16, 2012 at 7:28 AM, > >> wrote: >> >> >>> PS -- an example of the results can be found here: >>> >>> www.mcs.anl.gov/~fischer/ocyl.****gif >>> >>> > >>> >>> >>> >>> >>> On Thu, 16 Feb 2012, nek5000-users at lists.mcs.anl.****gov< >>> nek5000-users at lists.mcs.**anl.gov >>> >wrote: >>> >>> >>> Hi Pradeep, >>>> >>>> Attached is a case that appears to work. Hope this helps. >>>> >>>> Paul >>>> >>>> >>>> On Wed, 15 Feb 2012, nek5000-users at lists.mcs.anl.****gov< >>>> nek5000-users at lists.mcs.**anl.gov >>>> >wrote: >>>> >>>> Thanks Paul and Josh, >>>> >>>>> >>>>> I shall start by making the modification in the rea file and trying >>>>> visit >>>>> 2.3.2 >>>>> >>>>> Regards, >>>>> Pradeep >>>>> >>>>> On Wed, Feb 15, 2012 at 9:39 AM, >>>> nek5000-users at lists.mcs.**anl.gov >> >>>>> wrote: >>>>> >>>>> Pradeep, >>>>> >>>>>> >>>>>> Which version of Visit are you using? We have experienced similar >>>>>> issues with version 2.4 when viewing 2D meshes. If this is the case, >>>>>> try using 2.3.2 and see if you have the same problem. >>>>>> >>>>>> Josh >>>>>> >>>>>> On Tue, Feb 14, 2012 at 8:08 AM, >>>>> *gov >>>>>> >> >>>>>> >>>>>> wrote: >>>>>> >>>>>> Hi Neks, >>>>>>> >>>>>>> I'm trying to simulate 2D flow over an oscillating cylinder using >>>>>>> moving >>>>>>> mesh, and tried to set up a test case by looking at the peris >>>>>>> example. >>>>>>> I >>>>>>> however am getting vanishing Jacobians after the first few timesteps. >>>>>>> >>>>>>> I am modifying the the boundary velocity of the cylinder in userbc >>>>>>> >>>>>>> instead >>>>>> >>>>>> of userchk (as in the peris example). Would it be possible for you to >>>>>>> >>>>>>> look >>>>>> >>>>>> at my .usr file and tell me what I am doing wrong? >>>>>>> >>>>>>> I have attached the .rea, .usr, and SIZE with this mail. >>>>>>> >>>>>>> Further, when I try to view the mesh of the output (or the xyz fld >>>>>>> outputfile) in visit, visit crashes with the following error: >>>>>>> VisIt's viewer exited abnormally! Aborting the Graphical User >>>>>>> Interface. >>>>>>> >>>>>>> Lastly, would it be possible to simulate moving walls with large >>>>>>> deformations (i.e. where multiple elements get deformed), where the >>>>>>> deformation is known ahead of time? (eg. a flapping aerofoil) >>>>>>> >>>>>>> Thank you for your help! >>>>>>> >>>>>>> Regards, >>>>>>> Pradeep >>>>>>> >>>>>>> Extract from logfile: >>>>>>> >>>>>>> 60 U-PRES gmres: 100 7.5345E+42 1.0000E-02 4.0062E+57 >>>>>>> 6.7556E-03 1.5093E-02 >>>>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 >>>>>>> 16 >>>>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 >>>>>>> 16 >>>>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 >>>>>>> 16 >>>>>>> ERROR: alphad .le. 0 in econjp -1.31175831444004495E+179 >>>>>>> 16 >>>>>>> 60 DNORM, DIVEX 1.18120867781751263E+043 >>>>>>> 7.53448962619089522E+042 >>>>>>> 60 6.0000E-02 1.6697E-02 Fluid done >>>>>>> DT/DTCFL/DTFS/DTINIT 0.635E-45 0.635E-45 0.000E+00 >>>>>>> 0.100E-02 >>>>>>> Step 61, t= 6.0800000E-02, DT= 8.0000000E-04, C=******* >>>>>>> 2.2667E-01 >>>>>>> 1.8287E-02 >>>>>>> Solving for fluid >>>>>>> >>>>>>> >>>>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>>>> >>>>>>> 3. >>>>>> >>>>>> >>>>>>> >>>>>>> 2 ERROR: Vanishing Jacobian near 2th node of element >>>>>>> >>>>>>> 1. >>>>>> >>>>>> 2.27348348709230109E+081 -5.12478988977734591E+080 >>>>>>> -2.60483379627720531E+079 3.21465902039155941E+039 >>>>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>>>> >>>>>>> >>>>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>>>> >>>>>>> 4. >>>>>> >>>>>> 2 xyz: 1.25061E+38 4.64957E+39 >>>>>>> 9.79493533554062390E+080 -3.01548938509156252E+080 >>>>>>> 2 xyz: -2.46589E-08 -5.64092E-01 >>>>>>> >>>>>>> >>>>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>>>> 2 ERROR: Vanishing Jacobian near 3th node of element >>>>>>> >>>>>>> 2. >>>>>> >>>>>> >>>>>>> >>>>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>>>> >>>>>>> 5. >>>>>> >>>>>> 1.43125817410005932E+039 -6.03607926692375119E+038 >>>>>>> 5.54918579647991880E+039 -1.67302572815141788E+039 >>>>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>>>> 2 xyz: -2.46589E-08 -5.64092E-01 >>>>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>>>> >>>>>>> >>>>>>> 3 ERROR: Vanishing Jacobian near 2th node of element >>>>>>> >>>>>>> 6. >>>>>> >>>>>> 2 xyz: -3.07794E-08 -7.04112E-01 >>>>>>> >>>>>>> >>>>>>> 2 ERROR: Vanishing Jacobian near 7th node of element >>>>>>> >>>>>>> 7. >>>>>> >>>>>> 8.35923896949543198E+038 -3.55455289325888722E+038 >>>>>>> 3 xyz: -5.30056E+39 -5.84642E+39 >>>>>>> 1.21747337192549314E+039 -1.79454406120891328E+038 >>>>>>> 3 xyz: -5.24850E+39 -6.93109E+39 >>>>>>> 2 xyz: -5.66434E-08 -1.29581E+00 >>>>>>> 2 xyz: -6.27639E-08 -1.43583E+00 >>>>>>> >>>>>>> >>>>>>> 2 ERROR: Vanishing Jacobian near 9th node of element >>>>>>> >>>>>>> 8. >>>>>> >>>>>> 1.17802538305091326E+039 -4.21489851051369387E+038 >>>>>>> 2 xyz: -6.55671E-08 -1.49996E+00 >>>>>>> 2 xyz: -3.25016E+38 4.93026E+39 >>>>>>> call outfld: ifpsco: F >>>>>>> >>>>>>> 61 6.0800E-02 Write checkpoint: >>>>>>> >>>>>>> 61 6.0800E-02 OPEN: >>>>>>> xyzcyl2.fld01 >>>>>>> Jac error 1, setting p66=4, ifxyo=t >>>>>>> >>>>>>> call exitt: dying ... >>>>>>> >>>>>>> >>>>>>> ______________________________****_________________ >>>>>>> Nek5000-users mailing list >>>>>>> Nek5000-users at lists.mcs.anl.****gov >>>>>> gov > >>>>>>> https://lists.mcs.anl.gov/****mailman/listinfo/nek5000-users >>>>>>> ** >>>>>>> **> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Josh Camp >>>>>> >>>>>> "All that is necessary for the triumph of evil is that good men do >>>>>> nothing" -- Edmund Burke >>>>>> ______________________________****_________________ >>>>>> Nek5000-users mailing list >>>>>> Nek5000-users at lists.mcs.anl.****gov >>>>> 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 Tue Feb 28 10:21:53 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 10:21:53 -0600 (CST) Subject: [Nek5000-users] nek hangup in parallel (fwd) Message-ID: Paul, FYI -- I think we found the source of the problem (which is on our cluster -- or, really, in my script). I was previously using mpirun -np $(($nodes*$cores)) numa_wrapper -ppn=8 /scratch/mspragu2/tmp/nek5000 If I get rid of "numa_wrapper -ppn=8" in the above, nek is running, thankfully, well!!! Thanks much for running the test cases on your end. Cheers! --Mike From nek5000-users at lists.mcs.anl.gov Tue Feb 28 13:24:51 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 12:24:51 -0700 Subject: [Nek5000-users] write initial condition Message-ID: Hello neks. Is there a .rea flag or other simple solution to have nek write the initial-condition fld file regardless of the p015 IOSTEP choice? Thanks. --Mike From nek5000-users at lists.mcs.anl.gov Tue Feb 28 13:28:24 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 13:28:24 -0600 (CST) Subject: [Nek5000-users] write initial condition In-Reply-To: References: Message-ID: set nsteps to 0 and fintime to 0 ? On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hello neks. > > Is there a .rea flag or other simple solution to have nek write the initial-condition fld file regardless of the p015 IOSTEP choice? > > Thanks. > --Mike > > _______________________________________________ > 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 Feb 28 13:29:18 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 13:29:18 -0600 Subject: [Nek5000-users] write initial condition In-Reply-To: References: Message-ID: Hey Mike, An option I use is to put a simple statement in userchk() in the user file. Code is below if (istep.eq.0) call prepost(.true.,' ' ) Note that the second argument is a string containing three spaces. Let me know if this works for you. - Josh On Tue, Feb 28, 2012 at 1:24 PM, wrote: > Hello neks. > > Is there a .rea flag or other simple solution to have nek write the initial-condition fld file regardless of the p015 IOSTEP choice? > > Thanks. > --Mike > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Tue Feb 28 13:30:11 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 13:30:11 -0600 (CST) Subject: [Nek5000-users] write initial condition In-Reply-To: References: Message-ID: Sorry - I now see your question.. The only thing I know of is to add the following to userchk: if (istep.eq.0) call outpost(vx,vy,vz,pr,t,' ') You need something slightly different if you have multiple passive scalars. (you need output2() ... check the source for syntax.) Paul On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > > set nsteps to 0 and fintime to 0 ? > > > > On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello neks. >> >> Is there a .rea flag or other simple solution to have nek write the >> initial-condition fld file regardless of the p015 IOSTEP choice? >> >> Thanks. >> --Mike >> >> _______________________________________________ >> 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 Tue Feb 28 13:30:31 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 12:30:31 -0700 Subject: [Nek5000-users] write initial condition In-Reply-To: References: Message-ID: Yes, that would output the initial condition, but I'm looking for a solution that will output the initial condition for nsteps > 0, and iostep > 1 On Feb 28, 2012, at 12:28 PM, wrote: > > set nsteps to 0 and fintime to 0 ? > > > > On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello neks. >> >> Is there a .rea flag or other simple solution to have nek write the initial-condition fld file regardless of the p015 IOSTEP choice? >> >> Thanks. >> --Mike >> >> _______________________________________________ >> 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 Tue Feb 28 13:33:39 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 12:33:39 -0700 Subject: [Nek5000-users] write initial condition In-Reply-To: References: Message-ID: <85D0C0E4-EEAB-4304-948E-274E205693D0@nrel.gov> Paul & Josh, Thanks for your suggestions. I should be set with those. Paul, the IC-output might make a nice flag in the .rea file. There have been many instances where I've looked at my fld files thinking -- "what's up??" -- and wondering how the initial conditions looked. Cheers, Mike On Feb 28, 2012, at 12:30 PM, wrote: > > Sorry - I now see your question.. > > The only thing I know of is to add the following to userchk: > > if (istep.eq.0) call outpost(vx,vy,vz,pr,t,' ') > > > You need something slightly different if you have multiple > passive scalars. (you need output2() ... check the source > for syntax.) > > Paul > > > > > On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> >> set nsteps to 0 and fintime to 0 ? >> >> >> >> On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hello neks. >>> >>> Is there a .rea flag or other simple solution to have nek write the >>> initial-condition fld file regardless of the p015 IOSTEP choice? >>> >>> Thanks. >>> --Mike >>> >>> _______________________________________________ >>> 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 Tue Feb 28 13:44:44 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 13:44:44 -0600 (CST) Subject: [Nek5000-users] write initial condition In-Reply-To: <85D0C0E4-EEAB-4304-948E-274E205693D0@nrel.gov> References: <85D0C0E4-EEAB-4304-948E-274E205693D0@nrel.gov> Message-ID: Thanks Mike for the suggestion... I often achieve this result via: nekbmpi blah 32 echo 1 > ioinfo which tells nek to dump on the next step, which, if timing is good, should be the first. You're right, however, that we should make it a more certain thing. I'll talk with the group here about what would be a good flag to realize this. Paul On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Paul & Josh, > > Thanks for your suggestions. I should be set with those. > > Paul, the IC-output might make a nice flag in the .rea file. There have been many instances where I've looked at my fld files thinking -- "what's up??" -- and wondering how the initial conditions looked. > > Cheers, > Mike > > On Feb 28, 2012, at 12:30 PM, wrote: > >> >> Sorry - I now see your question.. >> >> The only thing I know of is to add the following to userchk: >> >> if (istep.eq.0) call outpost(vx,vy,vz,pr,t,' ') >> >> >> You need something slightly different if you have multiple >> passive scalars. (you need output2() ... check the source >> for syntax.) >> >> Paul >> >> >> >> >> On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> >>> set nsteps to 0 and fintime to 0 ? >>> >>> >>> >>> On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hello neks. >>>> >>>> Is there a .rea flag or other simple solution to have nek write the >>>> initial-condition fld file regardless of the p015 IOSTEP choice? >>>> >>>> Thanks. >>>> --Mike >>>> >>>> _______________________________________________ >>>> 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 Tue Feb 28 13:55:36 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 20:55:36 +0100 Subject: [Nek5000-users] stokes flow with time-dependent boundary In-Reply-To: References: <4EEF6A48.9090601@mech.kth.se> <4EF1ED90.702@mech.kth.se> <4EF24BC8.8030302@mech.kth.se> Message-ID: <1330458936.19986.44.camel@falketind.mech.kth.se> Hello, Paul, thank you for your reply. By following you suggestion, after switching the flag IFNAN to F, i can run unsteady stokes flow, however, if i want to run a single steady stokes flow, i switch the flag IFTRAN to F(i guess i am right here), but the simulation will break down. the first recorded error in the log file looks like 1 100 **ERROR**: Failed in HMHOLTZ: VELX 6.2080E-01 1.7717E+02 1.0000E-08 1.0000000000000000E-008 p22 1 1 1 1 Helmholtz VELY F: 0.0000E+00 1.0000E-08 1.0000E+00 0.0000E+00 1 Hmholtz VELY: 0 0.0000E+00 0.0000E+00 1.0000E-08 1 1.00000E-08 2.67182E-01 2.67182E-01 1.00000E+00 1 Divergence 1.0000000000000000E-008 p22 1 1 New CG1-tolerance (RINIT*epsm) = 5.4238943644626018E-014 any ideas on this? thanks in advance. lailai On Wed, 2011-12-21 at 15:17 -0600, nek5000-users at lists.mcs.anl.gov wrote: > Hi Lailai, > > I suggest initially starting with a single run, using steady Stokes. > (Note, steady Stokes works only for Pn-Pn-2, so set lx2,ly2 = lx1-2, etc.) > > Paul > > > On Wed, 21 Dec 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > thank you for your tip, Paul. > > > > i think we are solving a series of Stokes problems linked by a time-dependent > > boundary condition. > > The time-derivative term is zero and we are not solving an unsteady Stokes > > problem. I think we are not clear how to solve a series of Stokes problems. > > > > lailai > > > > > > > > > > > > On 12/21/2011 06:47 PM, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Lailai, > >> > >> To switch to unsteady Stokes, you simply set the flag > >> IFNAV to "F" in the .rea file, which turns off the convective > >> term and simultaneously eliminates the CFL timestep constraint. > >> > >> [ Set: > >> > >> T F F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) > >> > >> to > >> > >> F F F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) > >> > >> .] > >> > >> It's still not clear to me if you are solving an unsteady > >> Stokes problem, or a series of steady Stokes problems. > >> (There is a difference...) > >> > >> Nek can handle either case with equal ease. > >> > >> I hope this helps. > >> > >> Paul > >> > >> > >> On Wed, 21 Dec 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> > >>> On 12/19/2011 06:17 PM, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>> Hi Lailai, > >>>> > >>>> I have used the approach you proposed for solving multiple > >>>> steady stokes problems... you use an artificially large > >>>> timestep. That works. > >>>> > >>> > >>> thank for your reply, if understand correctly, here you are talking about > >>> the second approach i proposed. For each time step, we solve a transient > >>> problem with very large internal timestep to quickly get to the > >>> steady-state solution. > >>> since i am very new to nek5000, thus i am not sure how to implement this > >>> method which seems not trivial. > >>> > >>> On the other hand, i started from the first example of the Kovasznay > >>> problem. I remove the time-derivative and convection term by setting the > >>> density in .rea file to zero, the numerical results agree very well with > >>> the analytical solution with zero Re number. I guess here the solver is > >>> just inverting a matrix which seems feasible for a 2D problem but might be > >>> too expensive or inefficient for a 3D problem. > >>> > >>> > >>>> If you really have a time-dependent boundary condition, there > >>>> is no reason you can't just use the unsteady Stokes solver > >>>> with whatever timestep is required to accurately resolve your > >>>> temporal bcs. Note that, in this case, you would indeed have > >>>> the inertial term rho du/dt present in the physics. > >>>> > >>> > >>> > >>>> Paul > >>>> > >>>> > >>>> On Mon, 19 Dec 2011, nek5000-users at lists.mcs.anl.gov wrote: > >>>> > >>>>> Hello, guys, > >>>>> > >>>>> i am a new guy to Nek5000, i saw the manual of nek5000 that it can solve > >>>>> the steady stokes flow. > >>>>> i guess when i solve such a flow, do i need to set it as a transient > >>>>> simulation with time-derivative term included to get a steady-state > >>>>> solution? or, i can solve it by a direct solver method to get the > >>>>> solution immediately? > >>>>> > >>>>> since i want to add some time-dependent boundary condition for the > >>>>> steady stokes flow, so it will be pretty nice if i can solve it using > >>>>> the direct solver, for each time step, i solve one stokes flow; if > >>>>> nek5000 cannot solve it in such a way, i guess i have to use the first > >>>>> way; then for each time step i have to solve a transient problem to > >>>>> approach the steady state with some artificial time step used. > >>>>> > >>>>> i am not sure if i have stated my problem clearly. hopefully you guys > >>>>> have some experience on the feasibility of the two ways mentioned above. > >>>>> Thank you in advance. > >>>>> > >>>>> lailai > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Tue Feb 28 14:09:19 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 28 Feb 2012 14:09:19 -0600 (CST) Subject: [Nek5000-users] stokes flow with time-dependent boundary In-Reply-To: <1330458936.19986.44.camel@falketind.mech.kth.se> References: <4EEF6A48.9090601@mech.kth.se> <4EF1ED90.702@mech.kth.se> <4EF24BC8.8030302@mech.kth.se> <1330458936.19986.44.camel@falketind.mech.kth.se> Message-ID: Hi Lailai It's not clear that the simulation has broken down (nor that it hasn't). In particular, your divergence on the first iteration is relatively small, which is good. My guess is that this will ultimately converge. > 1 1.00000E-08 2.67182E-01 2.67182E-01 1.00000E+00 1 Divergence I would suggest to set the "divergence" and "helmholtz" parameters in your .rea file to be 0, and set tolrel and tolabs to be 0.01. Nek will then try to optimize the tolerance for the iterative solvers to give you a good solution with minimal computational overhead. Paul On Tue, 28 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hello, Paul, > > thank you for your reply. By following you suggestion, after switching > the flag IFNAN to F, i can run unsteady stokes flow, however, if i want > to run a single steady stokes flow, i switch the flag IFTRAN to F(i > guess i am right here), but the simulation will break down. the first > recorded error in the log file looks like > > 1 100 **ERROR**: Failed in HMHOLTZ: VELX 6.2080E-01 1.7717E+02 > 1.0000E-08 > 1.0000000000000000E-008 p22 1 1 > 1 1 Helmholtz VELY F: 0.0000E+00 1.0000E-08 1.0000E+00 > 0.0000E+00 > 1 Hmholtz VELY: 0 0.0000E+00 0.0000E+00 > 1.0000E-08 > 1 1.00000E-08 2.67182E-01 2.67182E-01 1.00000E+00 1 Divergence > 1.0000000000000000E-008 p22 1 1 > New CG1-tolerance (RINIT*epsm) = 5.4238943644626018E-014 > > any ideas on this? thanks in advance. > > lailai > > > > > On Wed, 2011-12-21 at 15:17 -0600, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Lailai, >> >> I suggest initially starting with a single run, using steady Stokes. >> (Note, steady Stokes works only for Pn-Pn-2, so set lx2,ly2 = lx1-2, etc.) >> >> Paul >> >> >> On Wed, 21 Dec 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> thank you for your tip, Paul. >>> >>> i think we are solving a series of Stokes problems linked by a time-dependent >>> boundary condition. >>> The time-derivative term is zero and we are not solving an unsteady Stokes >>> problem. I think we are not clear how to solve a series of Stokes problems. >>> >>> lailai >>> >>> >>> >>> >>> >>> On 12/21/2011 06:47 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>> Hi Lailai, >>>> >>>> To switch to unsteady Stokes, you simply set the flag >>>> IFNAV to "F" in the .rea file, which turns off the convective >>>> term and simultaneously eliminates the CFL timestep constraint. >>>> >>>> [ Set: >>>> >>>> T F F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) >>>> >>>> to >>>> >>>> F F F F F F F F F F F IFNAV & IFADVC (convection in P.S. fields) >>>> >>>> .] >>>> >>>> It's still not clear to me if you are solving an unsteady >>>> Stokes problem, or a series of steady Stokes problems. >>>> (There is a difference...) >>>> >>>> Nek can handle either case with equal ease. >>>> >>>> I hope this helps. >>>> >>>> Paul >>>> >>>> >>>> On Wed, 21 Dec 2011, nek5000-users at lists.mcs.anl.gov wrote: >>>> >>>>> On 12/19/2011 06:17 PM, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>> Hi Lailai, >>>>>> >>>>>> I have used the approach you proposed for solving multiple >>>>>> steady stokes problems... you use an artificially large >>>>>> timestep. That works. >>>>>> >>>>> >>>>> thank for your reply, if understand correctly, here you are talking about >>>>> the second approach i proposed. For each time step, we solve a transient >>>>> problem with very large internal timestep to quickly get to the >>>>> steady-state solution. >>>>> since i am very new to nek5000, thus i am not sure how to implement this >>>>> method which seems not trivial. >>>>> >>>>> On the other hand, i started from the first example of the Kovasznay >>>>> problem. I remove the time-derivative and convection term by setting the >>>>> density in .rea file to zero, the numerical results agree very well with >>>>> the analytical solution with zero Re number. I guess here the solver is >>>>> just inverting a matrix which seems feasible for a 2D problem but might be >>>>> too expensive or inefficient for a 3D problem. >>>>> >>>>> >>>>>> If you really have a time-dependent boundary condition, there >>>>>> is no reason you can't just use the unsteady Stokes solver >>>>>> with whatever timestep is required to accurately resolve your >>>>>> temporal bcs. Note that, in this case, you would indeed have >>>>>> the inertial term rho du/dt present in the physics. >>>>>> >>>>> >>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> On Mon, 19 Dec 2011, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> >>>>>>> Hello, guys, >>>>>>> >>>>>>> i am a new guy to Nek5000, i saw the manual of nek5000 that it can solve >>>>>>> the steady stokes flow. >>>>>>> i guess when i solve such a flow, do i need to set it as a transient >>>>>>> simulation with time-derivative term included to get a steady-state >>>>>>> solution? or, i can solve it by a direct solver method to get the >>>>>>> solution immediately? >>>>>>> >>>>>>> since i want to add some time-dependent boundary condition for the >>>>>>> steady stokes flow, so it will be pretty nice if i can solve it using >>>>>>> the direct solver, for each time step, i solve one stokes flow; if >>>>>>> nek5000 cannot solve it in such a way, i guess i have to use the first >>>>>>> way; then for each time step i have to solve a transient problem to >>>>>>> approach the steady state with some artificial time step used. >>>>>>> >>>>>>> i am not sure if i have stated my problem clearly. hopefully you guys >>>>>>> have some experience on the feasibility of the two ways mentioned above. >>>>>>> Thank you in advance. >>>>>>> >>>>>>> lailai >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Feb 10 15:34:27 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 10 Feb 2012 21:34:27 -0000 Subject: [Nek5000-users] Evaluate the validity of simulation results Message-ID: <977E8EBAA2E5E946A9311B0F429730FA7279E8F9D3@EXCHMBB.ornl.gov> Hi guys. I am a computer science guy without any background in fluid dynamics solver. I am using Nek5000 for the fault tolerance research. In particular, I inject random errors into data structures of Nek5000 and then record how Nek5000 reacts. Currently, I have a problem about how to judge the performance of Nek5K with injected faults is normal (i.e., tolerating fault) or not. I can simply record the execution time and then compare time difference. However, some injected errors might not lead to time variance while making the simulation result invalid. Is there any metric I can use to evaluate if the simulation result is valid/reasonable (especially for the eddy and/or vortex problem)? For example, a X error rate beyond a threshold after a fixed number of timesteps, or something? Thank you very much. -Dong -------------- next part -------------- An HTML attachment was scrubbed... URL: