From kmur at kft.umcs.lublin.pl Wed Aug 12 11:21:42 2009 From: kmur at kft.umcs.lublin.pl (Kris Murawski) Date: Wed, 12 Aug 2009 18:21:42 +0200 Subject: [FLASH-USERS] getting time-history in FLASH Message-ID: <4A82EC16.30808@kft.umcs.lublin.pl> Dear FLASH users, my intension is to dump plasma quantities such as a mass density, velocity, gas pressure and B in a given region. Such dumping has to be made every few time-steps. The dumping region can be defined as x_min< x < x_max y_min< y < y_max z_min< z < z_max Occasionally I may set x_min=x_max and y_min=y_max and draw a mass density vs. z and time such as in the attached figure. I wonder whether anyone went across such a problem and appreciate your hand in solving my problem. Getting your fortran and IDL coding would be provided by any credit you wish to get. Best wishes, Kris -------------- next part -------------- A non-text attachment was scrubbed... Name: density.eps Type: image/x-eps Size: 1341800 bytes Desc: not available Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20090812/4d78c69c/attachment.bin From gforjan at gmu.edu Wed Aug 12 20:43:42 2009 From: gforjan at gmu.edu (Gary F Forjan) Date: Wed, 12 Aug 2009 21:43:42 -0400 Subject: [FLASH-USERS] No flash3 Executable File Found Message-ID: Hello all Hope you are having an enjoyable summer. I recently downloaded FLASH3.2 and installed it on our SGI ALTIX ICE cluster. I tried to compile and run the Sedov explosion example as a test. After running the setup script, I moved to the object/ directory and typed gmake to build the executable (as described in the User's Guide). I believe I have the correct compilers and library paths set in my Makefile.h since it compiles all of the source code files and I get a SUCCESS at the end of it. Actually the last output lines are ut_quadraticInterpol.o workspace.o -L /sw//lib -lhdf5 SUCCESS gmake: warning: Clock skew detected. Your build may be incomplete. But I cannot find the flash3 executable in the object/ directory - as if the link step did not occur. I know I must be missing something basic but would anyone have an idea as to what might have happened. I have included my Makefile.h file below in case it is of any help. I am using an mpi wrapper for both the Intel fortran and cc compilers. I note that this makefile did work with FLASH2.5 on the same system. Thank you for any comments or suggestions. Best regards, Gary Gary Forjan Department of Computational and Data Sciences George Mason University, Fairfax, Va gforjan at gmu.edu ====================== MAKEFILE.H ============================= # FLASH makefile definitions for ix86 Linux (Portland Group compiler) # note, in order to get pgprof to work properly, it was necessary to # download a new version from ftp://ftp.pgroup.com/ that plays nicely # with GNOME. #---------------------------------------------------------------------------- # Set the HDF/HDF5 library paths -- these need to be updated for your system #---------------------------------------------------------------------------- #HDF4_PATH = /usr/local/hdf4 HDF4_PATH = #HDF5_PATH = /opt/HDF5-1.4.2-patch1-serial/ HDF5_PATH = /sw/ ZLIB_PATH = PAPI_PATH = PAPI_FLAGS = NCMPI_PATH = MPE_PATH = #---------------------------------------------------------------------------- # Compiler and linker commands # # Use the MPICH wrappers around the compilers -- these will automatically # load the proper libraries and include files. Version of MPICH prior # to 1.2.2 (?) do not recognize .F90 as a valid Fortran file extension. # You need to edit mpif90 and add .F90 to the test of filename extensions, # or upgrade your MPICH. #---------------------------------------------------------------------------- #FCOMP = mpif90 FCOMP = mpiifort CCOMP = mpiicc CPPCOMP = mpiiCC #LINK = mpif90 LINK = mpiifort # pre-processor flag PP = -D #---------------------------------------------------------------------------- # Compilation flags # # Three sets of compilation/linking flags are defined: one for optimized # code, one for testing, and one for debugging. The default is to use the # _OPT version. Specifying -debug to setup will pick the _DEBUG version, # these should enable bounds checking. Specifying _TEST is used for # flash_test, and is set for quick code generation, and (sometimes) # profiling. The Makefile generated by setup will assign the generic token # (ex. FFLAGS) to the proper set of flags (ex. FFLAGS_OPT). #---------------------------------------------------------------------------- #FFLAGS_OPT = -c -fast -r8 -i4 FFLAGS_OPT = -c -r8 -i4 FFLAGS_DEBUG = -g -c -Mbounds -r8 -i4 FFLAGS_TEST = -c -r8 -i4 -fast -Mprof=lines F90FLAGS = CFLAGS_OPT = -O2 -c CFLAGS_DEBUG = -g -c CFLAGS_TEST = -c # if we are using HDF5, we need to specify the path to the include files CFLAGS_HDF5 = -I $(HDF5_PATH)/include CFLAGS_NCMPI = #---------------------------------------------------------------------------- # Linker flags # # There is a seperate version of the linker flags for each of the _OPT, # _DEBUG, and _TEST cases. #---------------------------------------------------------------------------- LFLAGS_OPT = -o LFLAGS_DEBUG = -g -o LFLAGS_TEST = -Mprof=lines -o #---------------------------------------------------------------------------- # Library specific linking # # If a FLASH module has a 'LIBRARY xxx' line in its Config file, we need to # create a macro in this Makefile.h for LIB_xxx, which will be added to the # link line when FLASH is built. This allows us to switch between different # (incompatible) libraries. We also create a _OPT, _DEBUG, and _TEST # library macro to add any performance-minded libraries (like fast math), # depending on how FLASH was setup. #---------------------------------------------------------------------------- LIB_OPT = LIB_DEBUG = LIB_TEST = #LIB_HDF4 = -L $(HDF4_PATH)/lib -lmfhdf -ldf -ljpeg -lz LIB_HDF4 = LIB_HDF5 = -L $(HDF5_PATH)/lib -lhdf5 LIB_PAPI = LIB_MATH = -ldfftw -ldrfftw LIB_NCMPI = LIB_MPE = #---------------------------------------------------------------------------- # Additional machine-dependent object files # # Add any machine specific files here -- they will be compiled and linked # when FLASH is built. #---------------------------------------------------------------------------- MACHOBJ = #---------------------------------------------------------------------------- # Additional commands #---------------------------------------------------------------------------- MV = mv -f AR = ar -r RM = rm -f CD = cd RL = ranlib ECHO = echo From seyit at astro.rug.nl Thu Aug 13 05:50:15 2009 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Thu, 13 Aug 2009 12:50:15 +0200 Subject: [FLASH-USERS] No flash3 Executable File Found In-Reply-To: References: Message-ID: <4A83EFE7.6020009@astro.rug.nl> Hi Gary, I once had something weird as well a while ago. The executable was not flash3 but a.out or b.out. Check out if these files are there. Seyit Gary F Forjan wrote: > Hello all > > Hope you are having an enjoyable summer. I recently downloaded FLASH3.2 and installed it on our SGI ALTIX ICE cluster. I tried to compile and run the Sedov explosion example as a test. After running the setup script, I moved to the object/ directory and typed gmake to build the executable (as described in the User's Guide). I believe I have the correct compilers and library paths set in my Makefile.h since it compiles all of the source code files and I get a SUCCESS at the end of it. Actually the last output lines are > > ut_quadraticInterpol.o workspace.o -L /sw//lib -lhdf5 > SUCCESS > gmake: warning: Clock skew detected. Your build may be incomplete. > > > But I cannot find the flash3 executable in the object/ directory - as if the link step did not occur. I know I must be missing something basic but would anyone have an idea as to what might have happened. I have included my Makefile.h file below in case it is of any help. I am using an mpi wrapper for both the Intel fortran and cc compilers. I note that this makefile did work with FLASH2.5 on the same system. > > Thank you for any comments or suggestions. > > Best regards, > Gary > > Gary Forjan > Department of Computational and Data Sciences > George Mason University, Fairfax, Va > gforjan at gmu.edu > > ====================== MAKEFILE.H ============================= > > # FLASH makefile definitions for ix86 Linux (Portland Group compiler) > > # note, in order to get pgprof to work properly, it was necessary to > # download a new version from ftp://ftp.pgroup.com/ that plays nicely > # with GNOME. > > #---------------------------------------------------------------------------- > # Set the HDF/HDF5 library paths -- these need to be updated for your system > #---------------------------------------------------------------------------- > > #HDF4_PATH = /usr/local/hdf4 > HDF4_PATH = > #HDF5_PATH = /opt/HDF5-1.4.2-patch1-serial/ > HDF5_PATH = /sw/ > > ZLIB_PATH = > > PAPI_PATH = > PAPI_FLAGS = > > NCMPI_PATH = > MPE_PATH = > > #---------------------------------------------------------------------------- > # Compiler and linker commands > # > # Use the MPICH wrappers around the compilers -- these will automatically > # load the proper libraries and include files. Version of MPICH prior > # to 1.2.2 (?) do not recognize .F90 as a valid Fortran file extension. > # You need to edit mpif90 and add .F90 to the test of filename extensions, > # or upgrade your MPICH. > #---------------------------------------------------------------------------- > #FCOMP = mpif90 > FCOMP = mpiifort > CCOMP = mpiicc > CPPCOMP = mpiiCC > #LINK = mpif90 > LINK = mpiifort > # pre-processor flag > PP = -D > > #---------------------------------------------------------------------------- > # Compilation flags > # > # Three sets of compilation/linking flags are defined: one for optimized > # code, one for testing, and one for debugging. The default is to use the > # _OPT version. Specifying -debug to setup will pick the _DEBUG version, > # these should enable bounds checking. Specifying _TEST is used for > # flash_test, and is set for quick code generation, and (sometimes) > # profiling. The Makefile generated by setup will assign the generic token > # (ex. FFLAGS) to the proper set of flags (ex. FFLAGS_OPT). > #---------------------------------------------------------------------------- > > #FFLAGS_OPT = -c -fast -r8 -i4 > FFLAGS_OPT = -c -r8 -i4 > FFLAGS_DEBUG = -g -c -Mbounds -r8 -i4 > FFLAGS_TEST = -c -r8 -i4 -fast -Mprof=lines > > F90FLAGS = > > CFLAGS_OPT = -O2 -c > CFLAGS_DEBUG = -g -c > CFLAGS_TEST = -c > > # if we are using HDF5, we need to specify the path to the include files > CFLAGS_HDF5 = -I $(HDF5_PATH)/include > > CFLAGS_NCMPI = > > #---------------------------------------------------------------------------- > # Linker flags > # > # There is a seperate version of the linker flags for each of the _OPT, > # _DEBUG, and _TEST cases. > #---------------------------------------------------------------------------- > > LFLAGS_OPT = -o > LFLAGS_DEBUG = -g -o > LFLAGS_TEST = -Mprof=lines -o > > #---------------------------------------------------------------------------- > # Library specific linking > # > # If a FLASH module has a 'LIBRARY xxx' line in its Config file, we need to > # create a macro in this Makefile.h for LIB_xxx, which will be added to the > # link line when FLASH is built. This allows us to switch between different > # (incompatible) libraries. We also create a _OPT, _DEBUG, and _TEST > # library macro to add any performance-minded libraries (like fast math), > # depending on how FLASH was setup. > #---------------------------------------------------------------------------- > > LIB_OPT = > LIB_DEBUG = > LIB_TEST = > > #LIB_HDF4 = -L $(HDF4_PATH)/lib -lmfhdf -ldf -ljpeg -lz > LIB_HDF4 = > LIB_HDF5 = -L $(HDF5_PATH)/lib -lhdf5 > > LIB_PAPI = > LIB_MATH = -ldfftw -ldrfftw > > LIB_NCMPI = > LIB_MPE = > > #---------------------------------------------------------------------------- > # Additional machine-dependent object files > # > # Add any machine specific files here -- they will be compiled and linked > # when FLASH is built. > #---------------------------------------------------------------------------- > > MACHOBJ = > > > #---------------------------------------------------------------------------- > # Additional commands > #---------------------------------------------------------------------------- > > MV = mv -f > AR = ar -r > RM = rm -f > CD = cd > RL = ranlib > ECHO = echo > From gforjan at gmu.edu Thu Aug 13 06:58:36 2009 From: gforjan at gmu.edu (Gary F Forjan) Date: Thu, 13 Aug 2009 07:58:36 -0400 Subject: [FLASH-USERS] No flash3 Executable File Found In-Reply-To: <4A83EFE7.6020009@astro.rug.nl> References: <4A83EFE7.6020009@astro.rug.nl> Message-ID: Hi Seyit Thanks for the suggestion. I'll check my directory for these files... All the best, Gary Gary Forjan Department of Computational and Data Sciences George Mason University, Fairfax, Va gforjan at gmu.edu ----- Original Message ----- From: Seyit Hocuk Date: Thursday, August 13, 2009 6:50 am Subject: Re: [FLASH-USERS] No flash3 Executable File Found > Hi Gary, > > I once had something weird as well a while ago. The executable was > not > flash3 but a.out or b.out. > > Check out if these files are there. > > Seyit > > > > Gary F Forjan wrote: > > Hello all > > > > Hope you are having an enjoyable summer. I recently downloaded > FLASH3.2 and installed it on our SGI ALTIX ICE cluster. I tried > to compile and run the Sedov explosion example as a test. After > running the setup script, I moved to the object/ directory and > typed gmake to build the executable (as described in the User's > Guide). I believe I have the correct compilers and library paths > set in my Makefile.h since it compiles all of the source code > files and I get a SUCCESS at the end of it. Actually the last > output lines are > > > > ut_quadraticInterpol.o workspace.o -L /sw//lib -lhdf5 > > SUCCESS > > gmake: warning: Clock skew detected. Your build may be incomplete. > > > > > > But I cannot find the flash3 executable in the object/ directory > - as if the link step did not occur. I know I must be missing > something basic but would anyone have an idea as to what might > have happened. I have included my Makefile.h file below in case > it is of any help. I am using an mpi wrapper for both the Intel > fortran and cc compilers. I note that this makefile did work with > FLASH2.5 on the same system. > > > > Thank you for any comments or suggestions. > > > > Best regards, > > Gary > > > > Gary Forjan > > Department of Computational and Data Sciences > > George Mason University, Fairfax, Va > > gforjan at gmu.edu > > > > ====================== MAKEFILE.H ============================= > > > > # FLASH makefile definitions for ix86 Linux (Portland Group > compiler)> > > # note, in order to get pgprof to work properly, it was > necessary to > > # download a new version from ftp://ftp.pgroup.com/ that plays > nicely> # with GNOME. > > > > #---------------------------------------------------------------- > ------------ > > # Set the HDF/HDF5 library paths -- these need to be updated for > your system > > #---------------------------------------------------------------- > ------------ > > > > #HDF4_PATH = /usr/local/hdf4 > > HDF4_PATH = > > #HDF5_PATH = /opt/HDF5-1.4.2-patch1-serial/ > > HDF5_PATH = /sw/ > > > > ZLIB_PATH = > > > > PAPI_PATH = > > PAPI_FLAGS = > > > > NCMPI_PATH = > > MPE_PATH = > > > > #---------------------------------------------------------------- > ------------ > > # Compiler and linker commands > > # > > # Use the MPICH wrappers around the compilers -- these will > automatically> # load the proper libraries and include files. > Version of MPICH prior > > # to 1.2.2 (?) do not recognize .F90 as a valid Fortran file > extension.> # You need to edit mpif90 and add .F90 to the test > of filename extensions, > > # or upgrade your MPICH. > > #---------------------------------------------------------------- > ------------ > > #FCOMP = mpif90 > > FCOMP = mpiifort > > CCOMP = mpiicc > > CPPCOMP = mpiiCC > > #LINK = mpif90 > > LINK = mpiifort > > # pre-processor flag > > PP = -D > > > > #---------------------------------------------------------------- > ------------ > > # Compilation flags > > # > > # Three sets of compilation/linking flags are defined: one for > optimized> # code, one for testing, and one for debugging. The > default is to use the > > # _OPT version. Specifying -debug to setup will pick the > _DEBUG version, > > # these should enable bounds checking. Specifying _TEST is > used for > > # flash_test, and is set for quick code generation, and > (sometimes) > > # profiling. The Makefile generated by setup will assign the > generic token > > # (ex. FFLAGS) to the proper set of flags (ex. FFLAGS_OPT). > > #---------------------------------------------------------------- > ------------ > > > > #FFLAGS_OPT = -c -fast -r8 -i4 > > FFLAGS_OPT = -c -r8 -i4 > > FFLAGS_DEBUG = -g -c -Mbounds -r8 -i4 > > FFLAGS_TEST = -c -r8 -i4 -fast -Mprof=lines > > > > F90FLAGS = > > > > CFLAGS_OPT = -O2 -c > > CFLAGS_DEBUG = -g -c > > CFLAGS_TEST = -c > > > > # if we are using HDF5, we need to specify the path to the > include files > > CFLAGS_HDF5 = -I $(HDF5_PATH)/include > > > > CFLAGS_NCMPI = > > > > #---------------------------------------------------------------- > ------------ > > # Linker flags > > # > > # There is a seperate version of the linker flags for each of > the _OPT, > > # _DEBUG, and _TEST cases. > > #---------------------------------------------------------------- > ------------ > > > > LFLAGS_OPT = -o > > LFLAGS_DEBUG = -g -o > > LFLAGS_TEST = -Mprof=lines -o > > > > #---------------------------------------------------------------- > ------------ > > # Library specific linking > > # > > # If a FLASH module has a 'LIBRARY xxx' line in its Config > file, we need to > > # create a macro in this Makefile.h for LIB_xxx, which will be > added to the > > # link line when FLASH is built. This allows us to switch > between different > > # (incompatible) libraries. We also create a _OPT, _DEBUG, and > _TEST> # library macro to add any performance-minded libraries > (like fast math), > > # depending on how FLASH was setup. > > #---------------------------------------------------------------- > ------------ > > > > LIB_OPT = > > LIB_DEBUG = > > LIB_TEST = > > > > #LIB_HDF4 = -L $(HDF4_PATH)/lib -lmfhdf -ldf -ljpeg -lz > > LIB_HDF4 = > > LIB_HDF5 = -L $(HDF5_PATH)/lib -lhdf5 > > > > LIB_PAPI = > > LIB_MATH = -ldfftw -ldrfftw > > > > LIB_NCMPI = > > LIB_MPE = > > > > #---------------------------------------------------------------- > ------------ > > # Additional machine-dependent object files > > # > > # Add any machine specific files here -- they will be compiled > and linked > > # when FLASH is built. > > #---------------------------------------------------------------- > ------------ > > > > MACHOBJ = > > > > > > #---------------------------------------------------------------- > ------------ > > # Additional commands > > #---------------------------------------------------------------- > ------------ > > > > MV = mv -f > > AR = ar -r > > RM = rm -f > > CD = cd > > RL = ranlib > > ECHO = echo > > > > From gforjan at gmu.edu Fri Aug 14 20:04:05 2009 From: gforjan at gmu.edu (Gary F Forjan) Date: Fri, 14 Aug 2009 21:04:05 -0400 Subject: [FLASH-USERS] Fwd: Re: No flash3 Executable File Found Message-ID: Hi All Seyit was right. For some reason, gmake created a file called a.out in my object/ directory instead of flash3. I would appreciate it if someone could offer an explanation for why this happened so I can get the executable to be named flash3 when I run a new experiment. Anyway, I can work with FLASH3.2 now. Thanks for your help, Seyit. Best regards, Gary Gary Forjan Department of Computational and Data Sciences George Mason University, Fairfax, Va gforjan at gmu.edu -------------- next part -------------- An embedded message was scrubbed... From: Seyit Hocuk Subject: Re: [FLASH-USERS] No flash3 Executable File Found Date: Thu, 13 Aug 2009 12:50:15 +0200 Size: 7783 Url: http://flash.uchicago.edu/pipermail/flash-users/attachments/20090814/7f5cf457/attachment.mht From seyit at astro.rug.nl Mon Aug 17 05:25:42 2009 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Mon, 17 Aug 2009 12:25:42 +0200 Subject: [FLASH-USERS] Fwd: Re: No flash3 Executable File Found In-Reply-To: References: Message-ID: <4A893026.2030004@astro.rug.nl> Your Welcome Seyit Gary F Forjan wrote: > Hi All > > Seyit was right. For some reason, gmake created a file called a.out in my object/ directory instead of flash3. I would appreciate it if someone could offer an explanation for why this happened so I can get the executable to be named flash3 when I run a new experiment. Anyway, I can work with FLASH3.2 now. Thanks for your help, Seyit. > > Best regards, > Gary > > Gary Forjan > Department of Computational and Data Sciences > George Mason University, Fairfax, Va > gforjan at gmu.edu > > > ------------------------------------------------------------------------ > > Subject: > Re: [FLASH-USERS] No flash3 Executable File Found > From: > Seyit Hocuk > Date: > Thu, 13 Aug 2009 12:50:15 +0200 > To: > Gary F Forjan > > To: > Gary F Forjan > CC: > flash-users at flash.uchicago.edu > > > Hi Gary, > > I once had something weird as well a while ago. The executable was not > flash3 but a.out or b.out. > > Check out if these files are there. > > Seyit > > > > Gary F Forjan wrote: >> Hello all >> Hope you are having an enjoyable summer. I recently downloaded >> FLASH3.2 and installed it on our SGI ALTIX ICE cluster. I tried to >> compile and run the Sedov explosion example as a test. After running >> the setup script, I moved to the object/ directory and typed gmake to >> build the executable (as described in the User's Guide). I believe I >> have the correct compilers and library paths set in my Makefile.h >> since it compiles all of the source code files and I get a SUCCESS at >> the end of it. Actually the last output lines are >> ut_quadraticInterpol.o workspace.o -L /sw//lib -lhdf5 SUCCESS >> gmake: warning: Clock skew detected. Your build may be incomplete. >> >> >> But I cannot find the flash3 executable in the object/ directory - as >> if the link step did not occur. I know I must be missing something >> basic but would anyone have an idea as to what might have happened. >> I have included my Makefile.h file below in case it is of any help. >> I am using an mpi wrapper for both the Intel fortran and cc >> compilers. I note that this makefile did work with FLASH2.5 on the >> same system. >> >> Thank you for any comments or suggestions. >> >> Best regards, >> Gary >> Gary Forjan >> Department of Computational and Data Sciences >> George Mason University, Fairfax, Va >> gforjan at gmu.edu >> >> ====================== MAKEFILE.H ============================= >> >> # FLASH makefile definitions for ix86 Linux (Portland Group compiler) >> >> # note, in order to get pgprof to work properly, it was necessary to >> # download a new version from ftp://ftp.pgroup.com/ that plays nicely >> # with GNOME. >> >> #---------------------------------------------------------------------------- >> >> # Set the HDF/HDF5 library paths -- these need to be updated for your >> system >> #---------------------------------------------------------------------------- >> >> >> #HDF4_PATH = /usr/local/hdf4 >> HDF4_PATH = >> #HDF5_PATH = /opt/HDF5-1.4.2-patch1-serial/ >> HDF5_PATH = /sw/ >> >> ZLIB_PATH = >> >> PAPI_PATH = >> PAPI_FLAGS = >> >> NCMPI_PATH = >> MPE_PATH = >> >> #---------------------------------------------------------------------------- >> >> # Compiler and linker commands >> # >> # Use the MPICH wrappers around the compilers -- these will >> automatically >> # load the proper libraries and include files. Version of MPICH prior >> # to 1.2.2 (?) do not recognize .F90 as a valid Fortran file >> extension. >> # You need to edit mpif90 and add .F90 to the test of filename >> extensions, >> # or upgrade your MPICH. >> #---------------------------------------------------------------------------- >> >> #FCOMP = mpif90 >> FCOMP = mpiifort >> CCOMP = mpiicc >> CPPCOMP = mpiiCC >> #LINK = mpif90 >> LINK = mpiifort >> # pre-processor flag >> PP = -D >> #---------------------------------------------------------------------------- >> >> # Compilation flags >> # >> # Three sets of compilation/linking flags are defined: one for >> optimized >> # code, one for testing, and one for debugging. The default is to >> use the # _OPT version. Specifying -debug to setup will pick the >> _DEBUG version, >> # these should enable bounds checking. Specifying _TEST is used for >> # flash_test, and is set for quick code generation, and (sometimes) >> # profiling. The Makefile generated by setup will assign the >> generic token # (ex. FFLAGS) to the proper set of flags (ex. >> FFLAGS_OPT). >> #---------------------------------------------------------------------------- >> >> >> #FFLAGS_OPT = -c -fast -r8 -i4 FFLAGS_OPT = -c -r8 -i4 >> FFLAGS_DEBUG = -g -c -Mbounds -r8 -i4 FFLAGS_TEST = -c -r8 -i4 -fast >> -Mprof=lines >> >> F90FLAGS = >> >> CFLAGS_OPT = -O2 -c >> CFLAGS_DEBUG = -g -c >> CFLAGS_TEST = -c >> # if we are using HDF5, we need to specify the path to the include files >> CFLAGS_HDF5 = -I $(HDF5_PATH)/include >> >> CFLAGS_NCMPI = >> >> #---------------------------------------------------------------------------- >> >> # Linker flags >> # >> # There is a seperate version of the linker flags for each of the >> _OPT, # _DEBUG, and _TEST cases. >> #---------------------------------------------------------------------------- >> >> >> LFLAGS_OPT = -o >> LFLAGS_DEBUG = -g -o >> LFLAGS_TEST = -Mprof=lines -o >> >> #---------------------------------------------------------------------------- >> >> # Library specific linking >> # >> # If a FLASH module has a 'LIBRARY xxx' line in its Config file, we >> need to >> # create a macro in this Makefile.h for LIB_xxx, which will be added >> to the >> # link line when FLASH is built. This allows us to switch between >> different >> # (incompatible) libraries. We also create a _OPT, _DEBUG, and _TEST >> # library macro to add any performance-minded libraries (like fast >> math), >> # depending on how FLASH was setup. >> #---------------------------------------------------------------------------- >> >> >> LIB_OPT = LIB_DEBUG = >> LIB_TEST = >> #LIB_HDF4 = -L $(HDF4_PATH)/lib -lmfhdf -ldf -ljpeg -lz >> LIB_HDF4 = LIB_HDF5 = -L $(HDF5_PATH)/lib -lhdf5 >> >> LIB_PAPI = LIB_MATH = -ldfftw -ldrfftw >> >> LIB_NCMPI = >> LIB_MPE = >> >> #---------------------------------------------------------------------------- >> >> # Additional machine-dependent object files >> # >> # Add any machine specific files here -- they will be compiled and >> linked >> # when FLASH is built. >> #---------------------------------------------------------------------------- >> >> >> MACHOBJ = >> >> >> #---------------------------------------------------------------------------- >> >> # Additional commands >> #---------------------------------------------------------------------------- >> >> MV = mv -f >> AR = ar -r >> RM = rm -f >> CD = cd >> RL = ranlib >> ECHO = echo >> > From stratos at uiuc.edu Wed Aug 19 09:28:46 2009 From: stratos at uiuc.edu (Stratos Boutloukos) Date: Wed, 19 Aug 2009 10:28:46 -0400 Subject: [FLASH-USERS] Fwd: Re: No flash3 Executable File Found In-Reply-To: References: Message-ID: Hey Gary, In case you haven't figured out yourself by now, all you need to do is modify the Makefile; that is where the executable is defined. In the default Sedov Makefile the variable "EXE" is defined as "flash3" but at the definition of the executable further down there is an "-o" missing: $(EXE) : ..... ...... -o $(EXE)..... Most people probably changed that but didn't bother reporting. I think other test Makefiles don't suffer from this. Good luck Stratos On Aug 14, 2009, at 9:04 PM, Gary F Forjan wrote: > Hi All > > Seyit was right. For some reason, gmake created a file called > a.out in my object/ directory instead of flash3. I would > appreciate it if someone could offer an explanation for why this > happened so I can get the executable to be named flash3 when I run > a new experiment. Anyway, I can work with FLASH3.2 now. Thanks > for your help, Seyit. > > Best regards, > Gary > > Gary Forjan > Department of Computational and Data Sciences > George Mason University, Fairfax, Va > gforjan at gmu.edu > > From: Seyit Hocuk > Date: August 13, 2009 6:50:15 AM EDT > To: Gary F Forjan > Cc: flash-users at flash.uchicago.edu > Subject: Re: [FLASH-USERS] No flash3 Executable File Found > > > Hi Gary, > > I once had something weird as well a while ago. The executable was > not flash3 but a.out or b.out. > > Check out if these files are there. > > Seyit > > > > Gary F Forjan wrote: >> Hello all >> Hope you are having an enjoyable summer. I recently downloaded >> FLASH3.2 and installed it on our SGI ALTIX ICE cluster. I tried >> to compile and run the Sedov explosion example as a test. After >> running the setup script, I moved to the object/ directory and >> typed gmake to build the executable (as described in the User's >> Guide). I believe I have the correct compilers and library paths >> set in my Makefile.h since it compiles all of the source code >> files and I get a SUCCESS at the end of it. Actually the last >> output lines are >> ut_quadraticInterpol.o workspace.o -L /sw//lib -lhdf5 SUCCESS >> gmake: warning: Clock skew detected. Your build may be incomplete. >> >> >> But I cannot find the flash3 executable in the object/ directory - >> as if the link step did not occur. I know I must be missing >> something basic but would anyone have an idea as to what might >> have happened. I have included my Makefile.h file below in case >> it is of any help. I am using an mpi wrapper for both the Intel >> fortran and cc compilers. I note that this makefile did work with >> FLASH2.5 on the same system. >> >> Thank you for any comments or suggestions. >> >> Best regards, >> Gary >> Gary Forjan >> Department of Computational and Data Sciences >> George Mason University, Fairfax, Va >> gforjan at gmu.edu >> >> ====================== MAKEFILE.H ============================= >> >> # FLASH makefile definitions for ix86 Linux (Portland Group compiler) >> >> # note, in order to get pgprof to work properly, it was necessary >> to # download a new version from ftp://ftp.pgroup.com/ that plays >> nicely >> # with GNOME. >> >> #-------------------------------------------------------------------- >> -------- >> # Set the HDF/HDF5 library paths -- these need to be updated for >> your system >> #-------------------------------------------------------------------- >> -------- >> >> #HDF4_PATH = /usr/local/hdf4 >> HDF4_PATH = >> #HDF5_PATH = /opt/HDF5-1.4.2-patch1-serial/ >> HDF5_PATH = /sw/ >> >> ZLIB_PATH = >> >> PAPI_PATH = >> PAPI_FLAGS = >> >> NCMPI_PATH = >> MPE_PATH = >> >> #-------------------------------------------------------------------- >> -------- >> # Compiler and linker commands >> # >> # Use the MPICH wrappers around the compilers -- these will >> automatically >> # load the proper libraries and include files. Version of MPICH >> prior >> # to 1.2.2 (?) do not recognize .F90 as a valid Fortran file >> extension. >> # You need to edit mpif90 and add .F90 to the test of filename >> extensions, >> # or upgrade your MPICH. >> #-------------------------------------------------------------------- >> -------- >> #FCOMP = mpif90 >> FCOMP = mpiifort >> CCOMP = mpiicc >> CPPCOMP = mpiiCC >> #LINK = mpif90 >> LINK = mpiifort >> # pre-processor flag >> PP = -D >> #-------------------------------------------------------------------- >> -------- >> # Compilation flags >> # >> # Three sets of compilation/linking flags are defined: one for >> optimized >> # code, one for testing, and one for debugging. The default is >> to use the # _OPT version. Specifying -debug to setup will pick >> the _DEBUG version, >> # these should enable bounds checking. Specifying _TEST is used >> for # flash_test, and is set for quick code generation, and >> (sometimes) # profiling. The Makefile generated by setup will >> assign the generic token # (ex. FFLAGS) to the proper set of >> flags (ex. FFLAGS_OPT). >> #-------------------------------------------------------------------- >> -------- >> >> #FFLAGS_OPT = -c -fast -r8 -i4 FFLAGS_OPT = -c -r8 -i4 >> FFLAGS_DEBUG = -g -c -Mbounds -r8 -i4 FFLAGS_TEST = -c -r8 -i4 - >> fast -Mprof=lines >> >> F90FLAGS = >> >> CFLAGS_OPT = -O2 -c >> CFLAGS_DEBUG = -g -c >> CFLAGS_TEST = -c >> # if we are using HDF5, we need to specify the path to the include >> files >> CFLAGS_HDF5 = -I $(HDF5_PATH)/include >> >> CFLAGS_NCMPI = >> >> #-------------------------------------------------------------------- >> -------- >> # Linker flags >> # >> # There is a seperate version of the linker flags for each of the >> _OPT, # _DEBUG, and _TEST cases. >> #-------------------------------------------------------------------- >> -------- >> >> LFLAGS_OPT = -o >> LFLAGS_DEBUG = -g -o >> LFLAGS_TEST = -Mprof=lines -o >> >> #-------------------------------------------------------------------- >> -------- >> # Library specific linking >> # >> # If a FLASH module has a 'LIBRARY xxx' line in its Config file, >> we need to >> # create a macro in this Makefile.h for LIB_xxx, which will be >> added to the >> # link line when FLASH is built. This allows us to switch >> between different >> # (incompatible) libraries. We also create a _OPT, _DEBUG, and >> _TEST >> # library macro to add any performance-minded libraries (like >> fast math), >> # depending on how FLASH was setup. >> #-------------------------------------------------------------------- >> -------- >> >> LIB_OPT = LIB_DEBUG = >> LIB_TEST = >> #LIB_HDF4 = -L $(HDF4_PATH)/lib -lmfhdf -ldf -ljpeg -lz >> LIB_HDF4 = LIB_HDF5 = -L $(HDF5_PATH)/lib -lhdf5 >> >> LIB_PAPI = LIB_MATH = -ldfftw -ldrfftw >> >> LIB_NCMPI = >> LIB_MPE = >> >> #-------------------------------------------------------------------- >> -------- >> # Additional machine-dependent object files >> # >> # Add any machine specific files here -- they will be compiled >> and linked >> # when FLASH is built. >> #-------------------------------------------------------------------- >> -------- >> MACHOBJ = >> >> #-------------------------------------------------------------------- >> -------- >> # Additional commands >> #-------------------------------------------------------------------- >> -------- >> MV = mv -f >> AR = ar -r >> RM = rm -f >> CD = cd >> RL = ranlib >> ECHO = echo >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20090819/054a79f6/attachment.html From gforjan at gmu.edu Wed Aug 19 11:57:57 2009 From: gforjan at gmu.edu (Gary F Forjan) Date: Wed, 19 Aug 2009 12:57:57 -0400 Subject: [FLASH-USERS] Fwd: Re: No flash3 Executable File Found In-Reply-To: References: Message-ID: Hi Stratos Thank you for pointing out the problem. This was the only experiment I tried with FLASH3.2. I should have suspected a simple explanation but did not look closely enough at the Sedov makefile. Again, appreciate your response... Best regards, Gary Gary Forjan Department of Computational and Data Sciences George Mason University, Fairfax, Va gforjan at gmu.edu ----- Original Message ----- From: Stratos Boutloukos Date: Wednesday, August 19, 2009 10:28 am Subject: Re: [FLASH-USERS] Fwd: Re: No flash3 Executable File Found > Hey Gary, > > In case you haven't figured out yourself by now, all you need to > do > is modify the Makefile; that is where the executable is defined. > In > the default Sedov Makefile the variable "EXE" is defined as > "flash3" > but at the definition of the executable further down there is an "- > o" > missing: > $(EXE) : ..... > ...... -o $(EXE)..... > > Most people probably changed that but didn't bother reporting. I > think other test Makefiles don't suffer from this. > > Good luck > > Stratos > > On Aug 14, 2009, at 9:04 PM, Gary F Forjan wrote: > > > Hi All > > > > Seyit was right. For some reason, gmake created a file called > > a.out in my object/ directory instead of flash3. I would > > appreciate it if someone could offer an explanation for why this > > > happened so I can get the executable to be named flash3 when I > run > > a new experiment. Anyway, I can work with FLASH3.2 now. Thanks > > > for your help, Seyit. > > > > Best regards, > > Gary > > > > Gary Forjan > > Department of Computational and Data Sciences > > George Mason University, Fairfax, Va > > gforjan at gmu.edu > > > > From: Seyit Hocuk > > Date: August 13, 2009 6:50:15 AM EDT > > To: Gary F Forjan > > Cc: flash-users at flash.uchicago.edu > > Subject: Re: [FLASH-USERS] No flash3 Executable File Found > > > > > > Hi Gary, > > > > I once had something weird as well a while ago. The executable > was > > not flash3 but a.out or b.out. > > > > Check out if these files are there. > > > > Seyit > > > > > > > > Gary F Forjan wrote: > >> Hello all > >> Hope you are having an enjoyable summer. I recently downloaded > > >> FLASH3.2 and installed it on our SGI ALTIX ICE cluster. I > tried > >> to compile and run the Sedov explosion example as a test. > After > >> running the setup script, I moved to the object/ directory and > >> typed gmake to build the executable (as described in the User's > > >> Guide). I believe I have the correct compilers and library > paths > >> set in my Makefile.h since it compiles all of the source code > >> files and I get a SUCCESS at the end of it. Actually the last > >> output lines are > >> ut_quadraticInterpol.o workspace.o -L /sw//lib -lhdf5 SUCCESS > >> gmake: warning: Clock skew detected. Your build may be > incomplete.>> > >> > >> But I cannot find the flash3 executable in the object/ > directory - > >> as if the link step did not occur. I know I must be missing > >> something basic but would anyone have an idea as to what might > >> have happened. I have included my Makefile.h file below in > case > >> it is of any help. I am using an mpi wrapper for both the > Intel > >> fortran and cc compilers. I note that this makefile did work > with > >> FLASH2.5 on the same system. > >> > >> Thank you for any comments or suggestions. > >> > >> Best regards, > >> Gary > >> Gary Forjan > >> Department of Computational and Data Sciences > >> George Mason University, Fairfax, Va > >> gforjan at gmu.edu > >> > >> ====================== MAKEFILE.H ============================= > >> > >> # FLASH makefile definitions for ix86 Linux (Portland Group > compiler)>> > >> # note, in order to get pgprof to work properly, it was > necessary > >> to # download a new version from ftp://ftp.pgroup.com/ that > plays > >> nicely > >> # with GNOME. > >> > >> #--------------------------------------------------------------- > ----- > >> -------- > >> # Set the HDF/HDF5 library paths -- these need to be updated > for > >> your system > >> #--------------------------------------------------------------- > ----- > >> -------- > >> > >> #HDF4_PATH = /usr/local/hdf4 > >> HDF4_PATH = > >> #HDF5_PATH = /opt/HDF5-1.4.2-patch1-serial/ > >> HDF5_PATH = /sw/ > >> > >> ZLIB_PATH = > >> > >> PAPI_PATH = > >> PAPI_FLAGS = > >> > >> NCMPI_PATH = > >> MPE_PATH = > >> > >> #--------------------------------------------------------------- > ----- > >> -------- > >> # Compiler and linker commands > >> # > >> # Use the MPICH wrappers around the compilers -- these will > >> automatically > >> # load the proper libraries and include files. Version of > MPICH > >> prior > >> # to 1.2.2 (?) do not recognize .F90 as a valid Fortran file > >> extension. > >> # You need to edit mpif90 and add .F90 to the test of > filename > >> extensions, > >> # or upgrade your MPICH. > >> #--------------------------------------------------------------- > ----- > >> -------- > >> #FCOMP = mpif90 > >> FCOMP = mpiifort > >> CCOMP = mpiicc > >> CPPCOMP = mpiiCC > >> #LINK = mpif90 > >> LINK = mpiifort > >> # pre-processor flag > >> PP = -D > >> #--------------------------------------------------------------- > ----- > >> -------- > >> # Compilation flags > >> # > >> # Three sets of compilation/linking flags are defined: one for > > >> optimized > >> # code, one for testing, and one for debugging. The default > is > >> to use the # _OPT version. Specifying -debug to setup will > pick > >> the _DEBUG version, > >> # these should enable bounds checking. Specifying _TEST is > used > >> for # flash_test, and is set for quick code generation, and > >> (sometimes) # profiling. The Makefile generated by setup will > > >> assign the generic token # (ex. FFLAGS) to the proper set of > >> flags (ex. FFLAGS_OPT). > >> #--------------------------------------------------------------- > ----- > >> -------- > >> > >> #FFLAGS_OPT = -c -fast -r8 -i4 FFLAGS_OPT = -c -r8 -i4 > >> FFLAGS_DEBUG = -g -c -Mbounds -r8 -i4 FFLAGS_TEST = -c -r8 -i4 - > > >> fast -Mprof=lines > >> > >> F90FLAGS = > >> > >> CFLAGS_OPT = -O2 -c > >> CFLAGS_DEBUG = -g -c > >> CFLAGS_TEST = -c > >> # if we are using HDF5, we need to specify the path to the > include > >> files > >> CFLAGS_HDF5 = -I $(HDF5_PATH)/include > >> > >> CFLAGS_NCMPI = > >> > >> #--------------------------------------------------------------- > ----- > >> -------- > >> # Linker flags > >> # > >> # There is a seperate version of the linker flags for each of > the > >> _OPT, # _DEBUG, and _TEST cases. > >> #--------------------------------------------------------------- > ----- > >> -------- > >> > >> LFLAGS_OPT = -o > >> LFLAGS_DEBUG = -g -o > >> LFLAGS_TEST = -Mprof=lines -o > >> > >> #--------------------------------------------------------------- > ----- > >> -------- > >> # Library specific linking > >> # > >> # If a FLASH module has a 'LIBRARY xxx' line in its Config > file, > >> we need to > >> # create a macro in this Makefile.h for LIB_xxx, which will be > > >> added to the > >> # link line when FLASH is built. This allows us to switch > >> between different > >> # (incompatible) libraries. We also create a _OPT, _DEBUG, > and > >> _TEST > >> # library macro to add any performance-minded libraries (like > >> fast math), > >> # depending on how FLASH was setup. > >> #--------------------------------------------------------------- > ----- > >> -------- > >> > >> LIB_OPT = LIB_DEBUG = > >> LIB_TEST = > >> #LIB_HDF4 = -L $(HDF4_PATH)/lib -lmfhdf -ldf -ljpeg -lz > >> LIB_HDF4 = LIB_HDF5 = -L $(HDF5_PATH)/lib -lhdf5 > >> > >> LIB_PAPI = LIB_MATH = -ldfftw -ldrfftw > >> > >> LIB_NCMPI = > >> LIB_MPE = > >> > >> #--------------------------------------------------------------- > ----- > >> -------- > >> # Additional machine-dependent object files > >> # > >> # Add any machine specific files here -- they will be compiled > > >> and linked > >> # when FLASH is built. > >> #--------------------------------------------------------------- > ----- > >> -------- > >> MACHOBJ = > >> > >> #--------------------------------------------------------------- > ----- > >> -------- > >> # Additional commands > >> #--------------------------------------------------------------- > ----- > >> -------- > >> MV = mv -f > >> AR = ar -r > >> RM = rm -f > >> CD = cd > >> RL = ranlib > >> ECHO = echo > >> > > > > > > > > From turcotte at apollo.ubishops.ca Thu Aug 20 10:25:30 2009 From: turcotte at apollo.ubishops.ca (turcotte) Date: Thu, 20 Aug 2009 11:25:30 -0400 (EDT) Subject: [FLASH-USERS] Grid_bcApplyToRegionSpecialized Message-ID: <200908201525.n7KFPUm24821@apollo.ubishops.ca> Hello all, I am having problems using Grid_bcApplyToRegionSpecialized for a user defined BC. In the simplest case I am trying to reproduce what is done by Grid_applyBCEdge in Grid_bcApplyToRegionSpecialized, while keeping the routine as general as possible to change it to a more complicated BC. For a 2D box in cylindrical coordinates, applying the BC on the x=0 boundary, I loop thusly: applied=.true. sizeX=regionSize(BC_DIR) allocate(xCoord(sizeX)) sizeY=regionSize(2) allocate(yCoord(sizeY)) call Grid_getCellCoords(IAXIS,blockID,CENTER,.true.,xCoord,sizeX) call Grid_getCellCoords(JAXIS,blockID,CENTER,.true.,yCoord,sizeY) do j = 1,sizeY do i = 1,sizeX regionData(i,j,:,VELY_VAR) = value ! where value will be a function of xCoord(i) and yCoord(j) enddo enddo It works partly, but I have some data points, especially at cell boundaries where the BC does not hold value it should. If I make my BC a function of xCoord and yCoord then its behaviour worsens, which suggests I am missing something in the way the mesh is structured? I have also tried wrinting the loop as do i = 1,guard regionData(i,:,:,VELY_VAR) = value enddo which works better but still has some problems for some variables. Thanks. Sylvain From dongwook at flash.uchicago.edu Thu Aug 20 15:51:09 2009 From: dongwook at flash.uchicago.edu (Dongwook Lee) Date: Thu, 20 Aug 2009 15:51:09 -0500 (CDT) Subject: [FLASH-USERS] Grid_bcApplyToRegionSpecialized In-Reply-To: <200908201525.n7KFPUm24821@apollo.ubishops.ca> References: <200908201525.n7KFPUm24821@apollo.ubishops.ca> Message-ID: Hi Sylvain, I assume you're applying user BC only on the x=xmin boundary. If this is not true, and if you're also applying user BC on the y direction(s) with the current setups of x,y coordinates, this will not work for you, because your BC_DIR also varies. My first suggestion is to replace Grid_getCellCoords with gr_extendedGetCellCoords. This routine has an extended functionality that should be used internally within the Grid unit (i.e., should be called from Grid_*.F90) and can give you coordinate information even for remote blocks. I suggest your do loop look like (assuming userBC on x=xmin, i.e., axis=IAXIS, secondDir=JAXIS, thirdDir=KAXIS): (For more general cases, please have a look how secondDir and thirdDir are set in gr_bcApplyToOneFace.F90.) ------------------------------------------------------ sizeX = regionSize(axis) sizeY = regionSize(secondDir) sizeZ = regionSize(thirdDir) allocate(xCoord(sizeX)) allocate(yCoord(sizeY)) call gr_extendedGetCellCoords& (axis, blockHandle, gr_myPE, CENTER, .true., xCoord, sizeX) call gr_extendedGetCellCoords& (secondDir, blockHandle, gr_myPE, CENTER, .true., yCoord, sizeY) do i=1,guard do j=1,sizeY regionData(i,j,1:ke,VELY_VAR)=value(xCoord(i),yCoord(j)) enddo enddo --------------------------------------------------------- Note again that if you're applying userBC to x=xmax, as well as y=ymin or y=ymax, then you have to be more careful in setting up your xCoord and yCoord in using axis, secondDir as well as proper offsets for face=HIGH. If you need a BC for that case, I can give you an example of Grid_bcApplyToRegionSpecialized.F90 I've implemented. Hope this helps, Dongwook ---------------------------------------------------- Dongwook Lee, Ph.D., Research Scientist ASC Center for Astrophysical Thermonuclear Flashes University of Chicago 5640 S. Ellis, RI 484 (773) 834-6830 From klaus at flash.uchicago.edu Mon Aug 24 13:35:23 2009 From: klaus at flash.uchicago.edu (Klaus Weide) Date: Mon, 24 Aug 2009 13:35:23 -0500 (CDT) Subject: [FLASH-USERS] Grid_bcApplyToRegionSpecialized In-Reply-To: <200908201525.n7KFPUm24821@apollo.ubishops.ca> References: <200908201525.n7KFPUm24821@apollo.ubishops.ca> Message-ID: On Thu, 20 Aug 2009, turcotte wrote: Hello Sylvain, I think that the problems with your Grid_bcApplyToRegionSpecialized implementation are a result of neglecting an index offset for the y direction. I have inserted changes to fix this below (untested), as well as some other coments. For a more general template, I suggest you look at Grid/GridBoundaryConditions/OneRow/Grid_bcApplyToRegionSpecialized.F90; that version is basically an adapter from the Grid_bcApplyToRegionSpecialized to the Grid_applyBCEdge interface. > For a 2D box in cylindrical coordinates, applying the BC on the x=0 boundary, > I loop thusly: > applied=.true. > > sizeX=regionSize(BC_DIR) > allocate(xCoord(sizeX)) > > sizeY=regionSize(2) > allocate(yCoord(sizeY)) > > call Grid_getCellCoords(IAXIS,blockID,CENTER,.true.,xCoord,sizeX) > call Grid_getCellCoords(JAXIS,blockID,CENTER,.true.,yCoord,sizeY) You should use gr_extendedGetCellCoords instead of Grid_getCellCoords, as pointed out in Dongwook's response. Also declare an INTEGER variable jOffset, and use it like this: jOffset = endPoints(LOW,secondDir) - 1 > do j = 1,sizeY Note change in the index range in next line... > do i = 1,guard !was: sizeX > regionData(i,j,:,VELY_VAR) = value Note changed comment in next line... > ! where value will be a function of xCoord(i) and yCoord(j+jOffset) > enddo > enddo > I hope these changes fix your problems. As written, this will only be correct for the lower boundary in the x direction, and only for cell-centered variables (i.e., gridDataStruct==CENTER), so make sure your Grid_bcApplyToRegionSpecialized.F90 immediately returns (with applied = .FALSE.) when that is not the case. Klaus From klaus at flash.uchicago.edu Mon Aug 24 13:42:16 2009 From: klaus at flash.uchicago.edu (Klaus Weide) Date: Mon, 24 Aug 2009 13:42:16 -0500 (CDT) Subject: [FLASH-USERS] Grid_bcApplyToRegionSpecialized In-Reply-To: References: <200908201525.n7KFPUm24821@apollo.ubishops.ca> Message-ID: Sylvain and Dongwook, I believe Dongwook's code has several improvements (using gr_extendedGetCellCoords, correct upper bound in 'do i=1,guard' loop), but additionally needs an offset for the y direction, as indicated below. Klaus On Thu, 20 Aug 2009, Dongwook Lee wrote: > Hi Sylvain, > > I assume you're applying user BC only on the x=xmin boundary. > If this is not true, and if you're also applying user BC on the > y direction(s) with the current setups of x,y coordinates, this > will not work for you, because your BC_DIR also varies. > > My first suggestion is to replace Grid_getCellCoords with > gr_extendedGetCellCoords. This routine has an extended functionality > that should be used internally within the Grid > unit (i.e., should be called from Grid_*.F90) and can give you > coordinate information even for remote blocks. > > I suggest your do loop look like (assuming userBC on x=xmin, > i.e., axis=IAXIS, secondDir=JAXIS, thirdDir=KAXIS): > (For more general cases, please have a look how secondDir > and thirdDir are set in gr_bcApplyToOneFace.F90.) > > ------------------------------------------------------ > sizeX = regionSize(axis) > sizeY = regionSize(secondDir) > sizeZ = regionSize(thirdDir) > > allocate(xCoord(sizeX)) > allocate(yCoord(sizeY)) > > call gr_extendedGetCellCoords& > (axis, blockHandle, gr_myPE, CENTER, .true., xCoord, sizeX) > > call gr_extendedGetCellCoords& > (secondDir, blockHandle, gr_myPE, CENTER, .true., yCoord, sizeY) > jOffset = endPoints(LOW,secondDir) - 1 > do i=1,guard > do j=1,sizeY >! regionData(i,j,1:ke,VELY_VAR)=value(xCoord(i),yCoord(j)) regionData(i,j,1:ke,VELY_VAR)=value(xCoord(i),yCoord(j+jOffset)) > enddo > enddo > > --------------------------------------------------------- > > Note again that if you're applying userBC to x=xmax, as well > as y=ymin or y=ymax, then you have to be more careful in > setting up your xCoord and yCoord in using axis, secondDir > as well as proper offsets for face=HIGH. > > If you need a BC for that case, I can give you an example > of Grid_bcApplyToRegionSpecialized.F90 I've implemented. From turcotte at apollo.ubishops.ca Tue Aug 25 14:04:53 2009 From: turcotte at apollo.ubishops.ca (turcotte) Date: Tue, 25 Aug 2009 15:04:53 -0400 (EDT) Subject: [FLASH-USERS] Grid_bcApplyToRegionSpecialized Message-ID: <200908251904.n7PJ4rm27164@apollo.ubishops.ca> Hello Dongwook and Klaus, Many thanks for your suggestions. I will do that right away. Sylvain >Hi Sylvain, > >I assume you're applying user BC only on the x=xmin boundary. >If this is not true, and if you're also applying user BC on the >y direction(s) with the current setups of x,y coordinates, this >will not work for you, because your BC_DIR also varies. > >My first suggestion is to replace Grid_getCellCoords with >gr_extendedGetCellCoords. This routine has an extended functionality >that should be used internally within the Grid >unit (i.e., should be called from Grid_*.F90) and can give you >coordinate information even for remote blocks. > >I suggest your do loop look like (assuming userBC on x=xmin, >i.e., axis=IAXIS, secondDir=JAXIS, thirdDir=KAXIS): >(For more general cases, please have a look how secondDir >and thirdDir are set in gr_bcApplyToOneFace.F90.) > >------------------------------------------------------ >sizeX = regionSize(axis) >sizeY = regionSize(secondDir) >sizeZ = regionSize(thirdDir) > >allocate(xCoord(sizeX)) >allocate(yCoord(sizeY)) > >call gr_extendedGetCellCoords& > (axis, blockHandle, gr_myPE, CENTER, .true., xCoord, sizeX) > >call gr_extendedGetCellCoords& > (secondDir, blockHandle, gr_myPE, CENTER, .true., yCoord, sizeY) > >do i=1,guard > do j=1,sizeY > regionData(i,j,1:ke,VELY_VAR)=value(xCoord(i),yCoord(j)) > enddo >enddo > >--------------------------------------------------------- > >Note again that if you're applying userBC to x=xmax, as well >as y=ymin or y=ymax, then you have to be more careful in >setting up your xCoord and yCoord in using axis, secondDir >as well as proper offsets for face=HIGH. > >If you need a BC for that case, I can give you an example >of Grid_bcApplyToRegionSpecialized.F90 I've implemented. > >Hope this helps, >Dongwook > > >---------------------------------------------------- >Dongwook Lee, Ph.D., Research Scientist >ASC Center for Astrophysical Thermonuclear Flashes >University of Chicago >5640 S. Ellis, RI 484 >(773) 834-6830 > Sylvain Turcotte Physics Department turcotte at apollo.ubishops.ca Bishop's University tel: (819) 822-9600 x 2287 Lennoxville (Quebec) fax: (819) 822-9661 Canada J1M 1Z7 office: J 11B URL: http://apollo.ubishops.ca/~turcotte From jfg at ucolick.org Mon Aug 31 14:59:19 2009 From: jfg at ucolick.org (James Guillochon) Date: Mon, 31 Aug 2009 12:59:19 -0700 Subject: [FLASH-USERS] 4000+ cpus on Franklin Message-ID: <815AAC49-6FB6-499D-8DF0-5E8ED7A9F798@ucolick.org> Hi all, I'm trying to restart a FLASH simulation on Franklin. If I run on 2000 cpus, the job runs fine, however if I try to push the code to 4000 cpus, I get the following error: abort_message [flash_convert_cc_hook] Trying to convert non-zero mass- specific variable to per-volume form, but dens is zero! I've been guessing that it has something to do with memory allocation, so I've tried reducing MAXBLOCKS substantially (but still above the maximum number of blocks on a given processor), but this doesn't solve the problem. I've also played a bit with the MPICH parameters, but they also seem to have limited effect. Anyone have an idea of what I can try to do to solve this problem? Thanks! -- James Guillochon Department of Astronomy & Astrophysics University of California, Santa Cruz jfg at ucolick.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20090831/c663e5f7/attachment.html