From seyit at astro.rug.nl Mon Jun 2 11:20:20 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Mon, 02 Jun 2008 18:20:20 +0200 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 Message-ID: <48441DC4.9050701@astro.rug.nl> Hi, I am in the middle of switching to FLASH3.0 after a lot of suggestions to do that. However, whenever I compile a standard problem, while making I get the error message shown below. It might be related to my compiler or to HDF5. The compiler is this: /opt/intel/fce/10.1.012/bin/ifort HDF5 version: I tried both 1.6.6 and 1.6.7 The flags for the compiler I use are this: FFLAGS_OPT = -c -r8 -i4 -fast -ipo -I $(MPI_PATH)/include FFLAGS_DEBUG = -c -r8 -i4 -I $(MPI_PATH)/include FFLAGS_TEST = -c -r8 -i4 -I $(MPI_PATH)/include CFLAGS_HDF5 = -I $(HDF5_PATH)/include CFLAGS_OPT = -c -I$(MPI_PATH)/include CFLAGS_DEBUG = -c -g CFLAGS_TEST = -c -02 UNAME -a : Linux si01 2.6.22-14 #6 SMP Tue Mar 11 15:43:58 CET 2008 x86_64 GNU/Linux Does anyone have any experience on this problem. Thanks, Seyit workspace.o -L/home/users/seyit/Libraries/Hdf5-166/lib -lhdf5 -lz -L /home/users/seyit/mpi/mpich2/lib -lmpich ipo: warning #11043: unresolved H5Fclose Referenced in io_h5file_interface.o ipo: warning #11043: unresolved H5check_version Referenced in io_h5file_interface.o ipo: warning #11043: unresolved H5Fopen Referenced in io_h5file_interface.o ipo: warning #11043: unresolved H5Fcreate Referenced in io_h5file_interface.o ipo: warning #11043: unresolved H5Dopen Referenced in io_h5read_bflags.o Referenced in io_h5read_blk_particle_info.o Referenced in io_h5read_blksize.o Referenced in io_h5read_bndbox.o Referenced in io_h5read_coords.o Referenced in io_h5read_generic_int_arr.o Referenced in io_h5read_generic_real_arr.o Referenced in io_h5read_gid.o Referenced in io_h5read_lists.o Referenced in io_h5read_localnp.o Referenced in io_h5read_lrefine.o Referenced in io_h5read_nodetype.o Referenced in io_h5read_particles.o Referenced in io_h5read_unknowns.o Referenced in io_h5read_which_child.o Referenced in io_h5write_bflags.o Referenced in io_h5write_blk_particle_info.o Referenced in io_h5write_blksize.o ... ... ... etc. ... etc. ... ... amr_initialize.F90(734): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(735): (col. 9) remark: FUSED LOOP WAS VECTORIZED. amr_initialize.F90(737): (col. 9) remark: FUSED LOOP WAS VECTORIZED. amr_initialize.F90(741): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(742): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(838): (col. 7) remark: LOOP WAS VECTORIZED. amr_initialize.F90(839): (col. 7) remark: LOOP WAS VECTORIZED. gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS VECTORIZED. gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS VECTORIZED. Grid_dump.F90(156): (col. 11) remark: LOOP WAS VECTORIZED. PhysicalConstants_init.F90(127): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(130): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(133): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(136): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(139): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(142): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(145): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(148): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(151): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(154): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(157): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(160): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(165): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(167): (col. 8) remark: BLOCK WAS VECTORIZED. PhysicalConstants_init.F90(169): (col. 8) remark: BLOCK WAS VECTORIZED. Grid_init.F90(280): (col. 3) remark: LOOP WAS VECTORIZED. Grid_init.F90(375): (col. 3) remark: LOOP WAS VECTORIZED. Grid_init.F90(385): (col. 6) remark: LOOP WAS VECTORIZED. Particles_init.F90(108): (col. 3) remark: LOOP WAS VECTORIZED. Particles_init.F90(135): (col. 3) remark: LOOP WAS VECTORIZED. Particles_init.F90(182): (col. 6) remark: LOOP WAS VECTORIZED. Grid_initDomain.F90(96): (col. 11) remark: LOOP WAS VECTORIZED. Grid_initDomain.F90(114): (col. 20) remark: LOOP WAS VECTORIZED. Grid_initDomain.F90(117): (col. 12) remark: FUSED LOOP WAS VECTORIZED. Grid_initDomain.F90(124): (col. 17) remark: LOOP WAS VECTORIZED. Grid_initDomain.F90(133): (col. 17) remark: LOOP WAS VECTORIZED. Grid_initDomain.F90(136): (col. 14) remark: LOOP WAS VECTORIZED. Grid_initDomain.F90(171): (col. 12) remark: FUSED LOOP WAS VECTORIZED. Grid_initDomain.F90(189): (col. 14) remark: LOOP WAS VECTORIZED. Driver_verifyInitDt.F90(98): (col. 14) remark: LOOP WAS VECTORIZED. CosmologicalFunctions.F90(611): (col. 6) remark: LOOP WAS VECTORIZED. CosmologicalFunctions.F90(618): (col. 6) remark: LOOP WAS VECTORIZED. ld: skipping incompatible /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.so when searching for -lhdf5 ld: skipping incompatible /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.a when searching for -lhdf5 ld: cannot find -lhdf5 make: *** [flash3] Error 1 From dubey at flash.uchicago.edu Mon Jun 2 11:23:43 2008 From: dubey at flash.uchicago.edu (Anshu Dubey) Date: Mon, 2 Jun 2008 11:23:43 -0500 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <48441DC4.9050701@astro.rug.nl> References: <48441DC4.9050701@astro.rug.nl> Message-ID: <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> It appears that in your Makefile.h you haven't specified the correct path for hdf5 library. Anshu On Mon, Jun 2, 2008 at 11:20 AM, Seyit Hocuk wrote: > Hi, > > I am in the middle of switching to FLASH3.0 after a lot of suggestions to > do that. However, whenever I compile a standard problem, while making I get > the error message shown below. It might be related to my compiler or to > HDF5. > > The compiler is this: > /opt/intel/fce/10.1.012/bin/ifort > > HDF5 version: > I tried both 1.6.6 and 1.6.7 > > The flags for the compiler I use are this: > FFLAGS_OPT = -c -r8 -i4 -fast -ipo -I $(MPI_PATH)/include > FFLAGS_DEBUG = -c -r8 -i4 -I $(MPI_PATH)/include > FFLAGS_TEST = -c -r8 -i4 -I $(MPI_PATH)/include > > CFLAGS_HDF5 = -I $(HDF5_PATH)/include > > CFLAGS_OPT = -c -I$(MPI_PATH)/include > CFLAGS_DEBUG = -c -g > CFLAGS_TEST = -c -02 > > > UNAME -a : > Linux si01 2.6.22-14 #6 SMP Tue Mar 11 15:43:58 CET 2008 x86_64 GNU/Linux > > > > Does anyone have any experience on this problem. > > Thanks, > Seyit > > > > > > workspace.o -L/home/users/seyit/Libraries/Hdf5-166/lib -lhdf5 -lz -L > /home/users/seyit/mpi/mpich2/lib -lmpich > ipo: warning #11043: unresolved H5Fclose > Referenced in io_h5file_interface.o > ipo: warning #11043: unresolved H5check_version > Referenced in io_h5file_interface.o > ipo: warning #11043: unresolved H5Fopen > Referenced in io_h5file_interface.o > ipo: warning #11043: unresolved H5Fcreate > Referenced in io_h5file_interface.o > ipo: warning #11043: unresolved H5Dopen > Referenced in io_h5read_bflags.o > Referenced in io_h5read_blk_particle_info.o > Referenced in io_h5read_blksize.o > Referenced in io_h5read_bndbox.o > Referenced in io_h5read_coords.o > Referenced in io_h5read_generic_int_arr.o > Referenced in io_h5read_generic_real_arr.o > Referenced in io_h5read_gid.o > Referenced in io_h5read_lists.o > Referenced in io_h5read_localnp.o > Referenced in io_h5read_lrefine.o > Referenced in io_h5read_nodetype.o > Referenced in io_h5read_particles.o > Referenced in io_h5read_unknowns.o > Referenced in io_h5read_which_child.o > Referenced in io_h5write_bflags.o > Referenced in io_h5write_blk_particle_info.o > Referenced in io_h5write_blksize.o > ... > ... > ... etc. > ... etc. > ... > ... > amr_initialize.F90(734): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(735): (col. 9) remark: FUSED LOOP WAS VECTORIZED. > amr_initialize.F90(737): (col. 9) remark: FUSED LOOP WAS VECTORIZED. > amr_initialize.F90(741): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(742): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(838): (col. 7) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(839): (col. 7) remark: LOOP WAS VECTORIZED. > gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS VECTORIZED. > gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS VECTORIZED. > Grid_dump.F90(156): (col. 11) remark: LOOP WAS VECTORIZED. > PhysicalConstants_init.F90(127): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(130): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(133): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(136): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(139): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(142): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(145): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(148): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(151): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(154): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(157): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(160): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(165): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(167): (col. 8) remark: BLOCK WAS VECTORIZED. > PhysicalConstants_init.F90(169): (col. 8) remark: BLOCK WAS VECTORIZED. > Grid_init.F90(280): (col. 3) remark: LOOP WAS VECTORIZED. > Grid_init.F90(375): (col. 3) remark: LOOP WAS VECTORIZED. > Grid_init.F90(385): (col. 6) remark: LOOP WAS VECTORIZED. > Particles_init.F90(108): (col. 3) remark: LOOP WAS VECTORIZED. > Particles_init.F90(135): (col. 3) remark: LOOP WAS VECTORIZED. > Particles_init.F90(182): (col. 6) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(96): (col. 11) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(114): (col. 20) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(117): (col. 12) remark: FUSED LOOP WAS VECTORIZED. > Grid_initDomain.F90(124): (col. 17) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(133): (col. 17) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(136): (col. 14) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(171): (col. 12) remark: FUSED LOOP WAS VECTORIZED. > Grid_initDomain.F90(189): (col. 14) remark: LOOP WAS VECTORIZED. > Driver_verifyInitDt.F90(98): (col. 14) remark: LOOP WAS VECTORIZED. > CosmologicalFunctions.F90(611): (col. 6) remark: LOOP WAS VECTORIZED. > CosmologicalFunctions.F90(618): (col. 6) remark: LOOP WAS VECTORIZED. > ld: skipping incompatible > /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.so when searching for > -lhdf5 > ld: skipping incompatible > /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.a when searching for -lhdf5 > ld: cannot find -lhdf5 > make: *** [flash3] Error 1 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080602/5a850dc8/attachment.html From seyit at astro.rug.nl Tue Jun 3 09:56:42 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Tue, 03 Jun 2008 16:56:42 +0200 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> Message-ID: <48455BAA.8050405@astro.rug.nl> Hi, Putting the correct HDF5 path solved only part of the problem. I still have a lot of warnings and the simulation does not start, giving the error below, even though making ends with success. Both for FLASH2.5 and for FLASH3.0. Regards, Seyit. amr_prolong_cc_fun_init.F90(115): (col. 7) remark: LOOP WAS VECTORIZED. amr_prolong_cc_fun_init.F90(134): (col. 7) remark: LOOP WAS VECTORIZED. amr_prolong_cc_fun_init.F90(136): (col. 7) remark: LOOP WAS VECTORIZED. amr_prolong_cc_fun_init.F90(156): (col. 7) remark: LOOP WAS VECTORIZED. amr_prolong_cc_fun_init.F90(158): (col. 7) remark: LOOP WAS VECTORIZED. amr_initialize.F90(39): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(40): (col. 9) remark: FUSED LOOP WAS VECTORIZED. amr_initialize.F90(44): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(45): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(46): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(47): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(48): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(49): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(52): (col. 9) remark: LOOP WAS VECTORIZED. amr_initialize.F90(53): (col. 2) remark: FUSED LOOP WAS VECTORIZED. amr_initialize.F90(56): (col. 9) remark: FUSED LOOP WAS VECTORIZED. multifluid.F90(327): (col. 11) remark: FUSED LOOP WAS VECTORIZED. init_block.F90(220): (col. 7) remark: FUSED LOOP WAS VECTORIZED. init_block.F90(341): (col. 11) remark: FUSED LOOP WAS VECTORIZED. init_block.F90(347): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(347): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(347): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(348): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(348): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(348): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(349): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(349): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(349): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(350): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(350): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(350): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(351): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(351): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(351): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(353): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(353): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(353): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(354): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(354): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(354): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(356): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(356): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(356): (col. 16) remark: LOOP WAS VECTORIZED. init_block.F90(360): (col. 19) remark: LOOP WAS VECTORIZED. init_block.F90(360): (col. 19) remark: LOOP WAS VECTORIZED. init_block.F90(360): (col. 19) remark: LOOP WAS VECTORIZED. perfmon.F90(266): (col. 19) remark: LOOP WAS VECTORIZED. perfmon.F90(315): (col. 10) remark: LOOP WAS VECTORIZED. perfmon.F90(319): (col. 8) remark: PARTIAL LOOP WAS VECTORIZED. perfmon.F90(319): (col. 8) remark: PARTIAL LOOP WAS VECTORIZED. init_global_parms_checkpoint.F90(118): (col. 12) remark: LOOP WAS VECTORIZED. init_from_checkpoint.F90(139): (col. 18) remark: LOOP WAS VECTORIZED. init_from_checkpoint.F90(139): (col. 18) remark: LOOP WAS VECTORIZED. init_from_checkpoint.F90(141): (col. 18) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(196): (col. 11) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(196): (col. 11) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(197): (col. 6) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(198): (col. 11) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(233): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(233): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(234): (col. 12) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(235): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(239): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(239): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(241): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(247): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(247): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(249): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(266): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(266): (col. 17) remark: LOOP WAS VECTORIZED. init_from_scratch.F90(268): (col. 17) remark: LOOP WAS VECTORIZED. init_flash.F90(343): (col. 15) remark: PARTIAL LOOP WAS VECTORIZED. init_flash.F90(343): (col. 15) remark: PARTIAL LOOP WAS VECTORIZED. echo SUCCESS SUCCESS make[1]: Leaving directory `/home/users/seyit/FLASH2.5/object' seyit at si01:~/FLASH2.5/object$ ./flash2 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source libhdf5-1.6.5.so. 00002B76BF056F08 Unknown Unknown Unknown libhdf5-1.6.5.so. 00002B76BF05931F Unknown Unknown Unknown flash2 00000000004FFE9B Unknown Unknown Unknown flash2 00000000004EA435 Unknown Unknown Unknown flash2 00000000004F365B Unknown Unknown Unknown flash2 00000000004060E8 Unknown Unknown Unknown flash2 00000000004060A2 Unknown Unknown Unknown libc.so.6 00002B76BFBFEB44 Unknown Unknown Unknown flash2 0000000000405FE9 Unknown Unknown Unknown Anshu Dubey wrote: > It appears that in your Makefile.h you haven't specified the correct > path for hdf5 library. > Anshu > > On Mon, Jun 2, 2008 at 11:20 AM, Seyit Hocuk > wrote: > > Hi, > > I am in the middle of switching to FLASH3.0 after a lot of > suggestions to do that. However, whenever I compile a standard > problem, while making I get the error message shown below. It > might be related to my compiler or to HDF5. > > The compiler is this: > /opt/intel/fce/10.1.012/bin/ifort > > HDF5 version: > I tried both 1.6.6 and 1.6.7 > > The flags for the compiler I use are this: > FFLAGS_OPT = -c -r8 -i4 -fast -ipo -I $(MPI_PATH)/include > FFLAGS_DEBUG = -c -r8 -i4 -I $(MPI_PATH)/include > FFLAGS_TEST = -c -r8 -i4 -I $(MPI_PATH)/include > > CFLAGS_HDF5 = -I $(HDF5_PATH)/include > > CFLAGS_OPT = -c -I$(MPI_PATH)/include > CFLAGS_DEBUG = -c -g > CFLAGS_TEST = -c -02 > > > UNAME -a : > Linux si01 2.6.22-14 #6 SMP Tue Mar 11 15:43:58 CET 2008 x86_64 > GNU/Linux > > > > Does anyone have any experience on this problem. > > Thanks, > Seyit > > > > > > workspace.o -L/home/users/seyit/Libraries/Hdf5-166/lib -lhdf5 -lz > -L /home/users/seyit/mpi/mpich2/lib -lmpich > ipo: warning #11043: unresolved H5Fclose > Referenced in io_h5file_interface.o > ipo: warning #11043: unresolved H5check_version > Referenced in io_h5file_interface.o > ipo: warning #11043: unresolved H5Fopen > Referenced in io_h5file_interface.o > ipo: warning #11043: unresolved H5Fcreate > Referenced in io_h5file_interface.o > ipo: warning #11043: unresolved H5Dopen > Referenced in io_h5read_bflags.o > Referenced in io_h5read_blk_particle_info.o > Referenced in io_h5read_blksize.o > Referenced in io_h5read_bndbox.o > Referenced in io_h5read_coords.o > Referenced in io_h5read_generic_int_arr.o > Referenced in io_h5read_generic_real_arr.o > Referenced in io_h5read_gid.o > Referenced in io_h5read_lists.o > Referenced in io_h5read_localnp.o > Referenced in io_h5read_lrefine.o > Referenced in io_h5read_nodetype.o > Referenced in io_h5read_particles.o > Referenced in io_h5read_unknowns.o > Referenced in io_h5read_which_child.o > Referenced in io_h5write_bflags.o > Referenced in io_h5write_blk_particle_info.o > Referenced in io_h5write_blksize.o > ... > ... > ... etc. > ... etc. > ... > ... > amr_initialize.F90(734): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(735): (col. 9) remark: FUSED LOOP WAS VECTORIZED. > amr_initialize.F90(737): (col. 9) remark: FUSED LOOP WAS VECTORIZED. > amr_initialize.F90(741): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(742): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(838): (col. 7) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(839): (col. 7) remark: LOOP WAS VECTORIZED. > gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS VECTORIZED. > gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS VECTORIZED. > Grid_dump.F90(156): (col. 11) remark: LOOP WAS VECTORIZED. > PhysicalConstants_init.F90(127): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(130): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(133): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(136): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(139): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(142): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(145): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(148): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(151): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(154): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(157): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(160): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(165): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(167): (col. 8) remark: BLOCK WAS > VECTORIZED. > PhysicalConstants_init.F90(169): (col. 8) remark: BLOCK WAS > VECTORIZED. > Grid_init.F90(280): (col. 3) remark: LOOP WAS VECTORIZED. > Grid_init.F90(375): (col. 3) remark: LOOP WAS VECTORIZED. > Grid_init.F90(385): (col. 6) remark: LOOP WAS VECTORIZED. > Particles_init.F90(108): (col. 3) remark: LOOP WAS VECTORIZED. > Particles_init.F90(135): (col. 3) remark: LOOP WAS VECTORIZED. > Particles_init.F90(182): (col. 6) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(96): (col. 11) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(114): (col. 20) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(117): (col. 12) remark: FUSED LOOP WAS VECTORIZED. > Grid_initDomain.F90(124): (col. 17) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(133): (col. 17) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(136): (col. 14) remark: LOOP WAS VECTORIZED. > Grid_initDomain.F90(171): (col. 12) remark: FUSED LOOP WAS VECTORIZED. > Grid_initDomain.F90(189): (col. 14) remark: LOOP WAS VECTORIZED. > Driver_verifyInitDt.F90(98): (col. 14) remark: LOOP WAS VECTORIZED. > CosmologicalFunctions.F90(611): (col. 6) remark: LOOP WAS VECTORIZED. > CosmologicalFunctions.F90(618): (col. 6) remark: LOOP WAS VECTORIZED. > ld: skipping incompatible > /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.so when searching > for -lhdf5 > ld: skipping incompatible > /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.a when searching > for -lhdf5 > ld: cannot find -lhdf5 > make: *** [flash3] Error 1 > > From brockp at umich.edu Tue Jun 3 10:55:46 2008 From: brockp at umich.edu (Brock Palen) Date: Tue, 3 Jun 2008 11:55:46 -0400 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <48455BAA.8050405@astro.rug.nl> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> Message-ID: What is the output of ulimit -s on your system? Brock Palen www.umich.edu/~brockp Center for Advanced Computing brockp at umich.edu (734)936-1985 On Jun 3, 2008, at 10:56 AM, Seyit Hocuk wrote: > Hi, > > Putting the correct HDF5 path solved only part of the problem. I > still have a lot of warnings and the simulation does not start, > giving the error below, even though making ends with success. Both > for FLASH2.5 and for FLASH3.0. > > Regards, > Seyit. > > > > > > amr_prolong_cc_fun_init.F90(115): (col. 7) remark: LOOP WAS > VECTORIZED. > amr_prolong_cc_fun_init.F90(134): (col. 7) remark: LOOP WAS > VECTORIZED. > amr_prolong_cc_fun_init.F90(136): (col. 7) remark: LOOP WAS > VECTORIZED. > amr_prolong_cc_fun_init.F90(156): (col. 7) remark: LOOP WAS > VECTORIZED. > amr_prolong_cc_fun_init.F90(158): (col. 7) remark: LOOP WAS > VECTORIZED. > amr_initialize.F90(39): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(40): (col. 9) remark: FUSED LOOP WAS VECTORIZED. > amr_initialize.F90(44): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(45): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(46): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(47): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(48): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(49): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(52): (col. 9) remark: LOOP WAS VECTORIZED. > amr_initialize.F90(53): (col. 2) remark: FUSED LOOP WAS VECTORIZED. > amr_initialize.F90(56): (col. 9) remark: FUSED LOOP WAS VECTORIZED. > multifluid.F90(327): (col. 11) remark: FUSED LOOP WAS VECTORIZED. > init_block.F90(220): (col. 7) remark: FUSED LOOP WAS VECTORIZED. > init_block.F90(341): (col. 11) remark: FUSED LOOP WAS VECTORIZED. > init_block.F90(347): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(347): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(347): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(348): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(348): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(348): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(349): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(349): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(349): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(350): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(350): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(350): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(351): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(351): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(351): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(353): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(353): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(353): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(354): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(354): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(354): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(356): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(356): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(356): (col. 16) remark: LOOP WAS VECTORIZED. > init_block.F90(360): (col. 19) remark: LOOP WAS VECTORIZED. > init_block.F90(360): (col. 19) remark: LOOP WAS VECTORIZED. > init_block.F90(360): (col. 19) remark: LOOP WAS VECTORIZED. > perfmon.F90(266): (col. 19) remark: LOOP WAS VECTORIZED. > perfmon.F90(315): (col. 10) remark: LOOP WAS VECTORIZED. > perfmon.F90(319): (col. 8) remark: PARTIAL LOOP WAS VECTORIZED. > perfmon.F90(319): (col. 8) remark: PARTIAL LOOP WAS VECTORIZED. > init_global_parms_checkpoint.F90(118): (col. 12) remark: LOOP WAS > VECTORIZED. > init_from_checkpoint.F90(139): (col. 18) remark: LOOP WAS VECTORIZED. > init_from_checkpoint.F90(139): (col. 18) remark: LOOP WAS VECTORIZED. > init_from_checkpoint.F90(141): (col. 18) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(196): (col. 11) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(196): (col. 11) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(197): (col. 6) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(198): (col. 11) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(233): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(233): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(234): (col. 12) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(235): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(239): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(239): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(241): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(247): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(247): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(249): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(266): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(266): (col. 17) remark: LOOP WAS VECTORIZED. > init_from_scratch.F90(268): (col. 17) remark: LOOP WAS VECTORIZED. > init_flash.F90(343): (col. 15) remark: PARTIAL LOOP WAS VECTORIZED. > init_flash.F90(343): (col. 15) remark: PARTIAL LOOP WAS VECTORIZED. > echo SUCCESS > SUCCESS > make[1]: Leaving directory `/home/users/seyit/FLASH2.5/object' > seyit at si01:~/FLASH2.5/object$ ./flash2 > forrtl: severe (174): SIGSEGV, segmentation fault occurred > Image PC Routine Line > Source libhdf5-1.6.5.so. 00002B76BF056F08 > Unknown Unknown Unknown > libhdf5-1.6.5.so. 00002B76BF05931F Unknown Unknown > Unknown > flash2 00000000004FFE9B Unknown Unknown > Unknown > flash2 00000000004EA435 Unknown Unknown > Unknown > flash2 00000000004F365B Unknown Unknown > Unknown > flash2 00000000004060E8 Unknown Unknown > Unknown > flash2 00000000004060A2 Unknown Unknown > Unknown > libc.so.6 00002B76BFBFEB44 Unknown Unknown > Unknown > flash2 0000000000405FE9 Unknown Unknown > Unknown > > > > > > > > > > Anshu Dubey wrote: >> It appears that in your Makefile.h you haven't specified the >> correct path for hdf5 library. >> Anshu >> >> On Mon, Jun 2, 2008 at 11:20 AM, Seyit Hocuk > > wrote: >> >> Hi, >> >> I am in the middle of switching to FLASH3.0 after a lot of >> suggestions to do that. However, whenever I compile a standard >> problem, while making I get the error message shown below. It >> might be related to my compiler or to HDF5. >> >> The compiler is this: >> /opt/intel/fce/10.1.012/bin/ifort >> >> HDF5 version: >> I tried both 1.6.6 and 1.6.7 >> >> The flags for the compiler I use are this: >> FFLAGS_OPT = -c -r8 -i4 -fast -ipo -I $(MPI_PATH)/include >> FFLAGS_DEBUG = -c -r8 -i4 -I $(MPI_PATH)/include >> FFLAGS_TEST = -c -r8 -i4 -I $(MPI_PATH)/include >> >> CFLAGS_HDF5 = -I $(HDF5_PATH)/include >> >> CFLAGS_OPT = -c -I$(MPI_PATH)/include >> CFLAGS_DEBUG = -c -g >> CFLAGS_TEST = -c -02 >> >> >> UNAME -a : >> Linux si01 2.6.22-14 #6 SMP Tue Mar 11 15:43:58 CET 2008 x86_64 >> GNU/Linux >> >> >> >> Does anyone have any experience on this problem. >> >> Thanks, >> Seyit >> >> >> >> >> >> workspace.o -L/home/users/seyit/Libraries/Hdf5-166/lib -lhdf5 -lz >> -L /home/users/seyit/mpi/mpich2/lib -lmpich >> ipo: warning #11043: unresolved H5Fclose >> Referenced in io_h5file_interface.o >> ipo: warning #11043: unresolved H5check_version >> Referenced in io_h5file_interface.o >> ipo: warning #11043: unresolved H5Fopen >> Referenced in io_h5file_interface.o >> ipo: warning #11043: unresolved H5Fcreate >> Referenced in io_h5file_interface.o >> ipo: warning #11043: unresolved H5Dopen >> Referenced in io_h5read_bflags.o >> Referenced in io_h5read_blk_particle_info.o >> Referenced in io_h5read_blksize.o >> Referenced in io_h5read_bndbox.o >> Referenced in io_h5read_coords.o >> Referenced in io_h5read_generic_int_arr.o >> Referenced in io_h5read_generic_real_arr.o >> Referenced in io_h5read_gid.o >> Referenced in io_h5read_lists.o >> Referenced in io_h5read_localnp.o >> Referenced in io_h5read_lrefine.o >> Referenced in io_h5read_nodetype.o >> Referenced in io_h5read_particles.o >> Referenced in io_h5read_unknowns.o >> Referenced in io_h5read_which_child.o >> Referenced in io_h5write_bflags.o >> Referenced in io_h5write_blk_particle_info.o >> Referenced in io_h5write_blksize.o >> ... >> ... >> ... etc. >> ... etc. >> ... >> ... >> amr_initialize.F90(734): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(735): (col. 9) remark: FUSED LOOP WAS >> VECTORIZED. >> amr_initialize.F90(737): (col. 9) remark: FUSED LOOP WAS >> VECTORIZED. >> amr_initialize.F90(741): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(742): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(838): (col. 7) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(839): (col. 7) remark: LOOP WAS VECTORIZED. >> gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS >> VECTORIZED. >> gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS >> VECTORIZED. >> Grid_dump.F90(156): (col. 11) remark: LOOP WAS VECTORIZED. >> PhysicalConstants_init.F90(127): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(130): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(133): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(136): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(139): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(142): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(145): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(148): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(151): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(154): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(157): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(160): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(165): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(167): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> PhysicalConstants_init.F90(169): (col. 8) remark: BLOCK WAS >> VECTORIZED. >> Grid_init.F90(280): (col. 3) remark: LOOP WAS VECTORIZED. >> Grid_init.F90(375): (col. 3) remark: LOOP WAS VECTORIZED. >> Grid_init.F90(385): (col. 6) remark: LOOP WAS VECTORIZED. >> Particles_init.F90(108): (col. 3) remark: LOOP WAS VECTORIZED. >> Particles_init.F90(135): (col. 3) remark: LOOP WAS VECTORIZED. >> Particles_init.F90(182): (col. 6) remark: LOOP WAS VECTORIZED. >> Grid_initDomain.F90(96): (col. 11) remark: LOOP WAS VECTORIZED. >> Grid_initDomain.F90(114): (col. 20) remark: LOOP WAS VECTORIZED. >> Grid_initDomain.F90(117): (col. 12) remark: FUSED LOOP WAS >> VECTORIZED. >> Grid_initDomain.F90(124): (col. 17) remark: LOOP WAS VECTORIZED. >> Grid_initDomain.F90(133): (col. 17) remark: LOOP WAS VECTORIZED. >> Grid_initDomain.F90(136): (col. 14) remark: LOOP WAS VECTORIZED. >> Grid_initDomain.F90(171): (col. 12) remark: FUSED LOOP WAS >> VECTORIZED. >> Grid_initDomain.F90(189): (col. 14) remark: LOOP WAS VECTORIZED. >> Driver_verifyInitDt.F90(98): (col. 14) remark: LOOP WAS >> VECTORIZED. >> CosmologicalFunctions.F90(611): (col. 6) remark: LOOP WAS >> VECTORIZED. >> CosmologicalFunctions.F90(618): (col. 6) remark: LOOP WAS >> VECTORIZED. >> ld: skipping incompatible >> /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.so when >> searching >> for -lhdf5 >> ld: skipping incompatible >> /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.a when searching >> for -lhdf5 >> ld: cannot find -lhdf5 >> make: *** [flash3] Error 1 >> >> > > > From nhearn at uchicago.edu Tue Jun 3 12:10:35 2008 From: nhearn at uchicago.edu (Nathan Hearn) Date: Tue, 3 Jun 2008 12:10:35 -0500 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <48455BAA.8050405@astro.rug.nl> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> Message-ID: <2467fdc0806031010p22ed2a2bwb7bf9d4497af5d95@mail.gmail.com> Hi Seyit, Looking at the compiler output that you showed, I don't see any warnings. The "remark" statements that you see are just the Intel compiler's way of declaring that it produced vectorized (SSE2+) code for some of the loops. (The compiler is apparently very happy when this happens...) But yes, there is certainly a problem at runtime. I noticed that you are using fairly aggressive optimizations (i.e., the "-fast -ipo" flags in FFLAGS_OPT). Have you tested the code without optimizations? (Running setup with the -debug flag will result in the FFLAGS_DEBUG options being used instead of FFLAGS_OPT.) - Nathan On Tue, Jun 3, 2008 at 9:56 AM, Seyit Hocuk wrote: > Hi, > > Putting the correct HDF5 path solved only part of the problem. I still have > a lot of warnings and the simulation does not start, giving the error below, > even though making ends with success. Both for FLASH2.5 and for FLASH3.0. > > Regards, > Seyit. From seyit at astro.rug.nl Tue Jun 3 12:20:06 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Tue, 03 Jun 2008 19:20:06 +0200 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> Message-ID: <48457D46.8080406@astro.rug.nl> ulimit -s 8192 Brock Palen wrote: > What is the output of > > ulimit -s > > on your system? > > Brock Palen > www.umich.edu/~brockp > Center for Advanced Computing > brockp at umich.edu > (734)936-1985 > > > > On Jun 3, 2008, at 10:56 AM, Seyit Hocuk wrote: >> Hi, >> >> Putting the correct HDF5 path solved only part of the problem. I >> still have a lot of warnings and the simulation does not start, >> giving the error below, even though making ends with success. Both >> for FLASH2.5 and for FLASH3.0. >> >> Regards, >> Seyit. >> >> >> >> >> >> amr_prolong_cc_fun_init.F90(115): (col. 7) remark: LOOP WAS VECTORIZED. >> amr_prolong_cc_fun_init.F90(134): (col. 7) remark: LOOP WAS VECTORIZED. >> amr_prolong_cc_fun_init.F90(136): (col. 7) remark: LOOP WAS VECTORIZED. >> amr_prolong_cc_fun_init.F90(156): (col. 7) remark: LOOP WAS VECTORIZED. >> amr_prolong_cc_fun_init.F90(158): (col. 7) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(39): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(40): (col. 9) remark: FUSED LOOP WAS VECTORIZED. >> amr_initialize.F90(44): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(45): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(46): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(47): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(48): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(49): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(52): (col. 9) remark: LOOP WAS VECTORIZED. >> amr_initialize.F90(53): (col. 2) remark: FUSED LOOP WAS VECTORIZED. >> amr_initialize.F90(56): (col. 9) remark: FUSED LOOP WAS VECTORIZED. >> multifluid.F90(327): (col. 11) remark: FUSED LOOP WAS VECTORIZED. >> init_block.F90(220): (col. 7) remark: FUSED LOOP WAS VECTORIZED. >> init_block.F90(341): (col. 11) remark: FUSED LOOP WAS VECTORIZED. >> init_block.F90(347): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(347): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(347): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(348): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(348): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(348): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(349): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(349): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(349): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(350): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(350): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(350): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(351): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(351): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(351): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(353): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(353): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(353): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(354): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(354): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(354): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(356): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(356): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(356): (col. 16) remark: LOOP WAS VECTORIZED. >> init_block.F90(360): (col. 19) remark: LOOP WAS VECTORIZED. >> init_block.F90(360): (col. 19) remark: LOOP WAS VECTORIZED. >> init_block.F90(360): (col. 19) remark: LOOP WAS VECTORIZED. >> perfmon.F90(266): (col. 19) remark: LOOP WAS VECTORIZED. >> perfmon.F90(315): (col. 10) remark: LOOP WAS VECTORIZED. >> perfmon.F90(319): (col. 8) remark: PARTIAL LOOP WAS VECTORIZED. >> perfmon.F90(319): (col. 8) remark: PARTIAL LOOP WAS VECTORIZED. >> init_global_parms_checkpoint.F90(118): (col. 12) remark: LOOP WAS >> VECTORIZED. >> init_from_checkpoint.F90(139): (col. 18) remark: LOOP WAS VECTORIZED. >> init_from_checkpoint.F90(139): (col. 18) remark: LOOP WAS VECTORIZED. >> init_from_checkpoint.F90(141): (col. 18) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(196): (col. 11) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(196): (col. 11) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(197): (col. 6) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(198): (col. 11) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(233): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(233): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(234): (col. 12) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(235): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(239): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(239): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(241): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(247): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(247): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(249): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(266): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(266): (col. 17) remark: LOOP WAS VECTORIZED. >> init_from_scratch.F90(268): (col. 17) remark: LOOP WAS VECTORIZED. >> init_flash.F90(343): (col. 15) remark: PARTIAL LOOP WAS VECTORIZED. >> init_flash.F90(343): (col. 15) remark: PARTIAL LOOP WAS VECTORIZED. >> echo SUCCESS >> SUCCESS >> make[1]: Leaving directory `/home/users/seyit/FLASH2.5/object' >> seyit at si01:~/FLASH2.5/object$ ./flash2 >> forrtl: severe (174): SIGSEGV, segmentation fault occurred >> Image PC Routine Line >> Source libhdf5-1.6.5.so. 00002B76BF056F08 >> Unknown Unknown Unknown >> libhdf5-1.6.5.so. 00002B76BF05931F Unknown Unknown >> Unknown >> flash2 00000000004FFE9B Unknown Unknown >> Unknown >> flash2 00000000004EA435 Unknown Unknown >> Unknown >> flash2 00000000004F365B Unknown Unknown >> Unknown >> flash2 00000000004060E8 Unknown Unknown >> Unknown >> flash2 00000000004060A2 Unknown Unknown >> Unknown >> libc.so.6 00002B76BFBFEB44 Unknown Unknown >> Unknown >> flash2 0000000000405FE9 Unknown Unknown >> Unknown >> >> >> >> >> >> >> >> >> >> Anshu Dubey wrote: >>> It appears that in your Makefile.h you haven't specified the correct >>> path for hdf5 library. >>> Anshu >>> >>> On Mon, Jun 2, 2008 at 11:20 AM, Seyit Hocuk >> > wrote: >>> >>> Hi, >>> >>> I am in the middle of switching to FLASH3.0 after a lot of >>> suggestions to do that. However, whenever I compile a standard >>> problem, while making I get the error message shown below. It >>> might be related to my compiler or to HDF5. >>> >>> The compiler is this: >>> /opt/intel/fce/10.1.012/bin/ifort >>> >>> HDF5 version: >>> I tried both 1.6.6 and 1.6.7 >>> >>> The flags for the compiler I use are this: >>> FFLAGS_OPT = -c -r8 -i4 -fast -ipo -I $(MPI_PATH)/include >>> FFLAGS_DEBUG = -c -r8 -i4 -I $(MPI_PATH)/include >>> FFLAGS_TEST = -c -r8 -i4 -I $(MPI_PATH)/include >>> >>> CFLAGS_HDF5 = -I $(HDF5_PATH)/include >>> >>> CFLAGS_OPT = -c -I$(MPI_PATH)/include >>> CFLAGS_DEBUG = -c -g >>> CFLAGS_TEST = -c -02 >>> >>> >>> UNAME -a : >>> Linux si01 2.6.22-14 #6 SMP Tue Mar 11 15:43:58 CET 2008 x86_64 >>> GNU/Linux >>> >>> >>> >>> Does anyone have any experience on this problem. >>> >>> Thanks, >>> Seyit >>> >>> >>> >>> >>> >>> workspace.o -L/home/users/seyit/Libraries/Hdf5-166/lib -lhdf5 -lz >>> -L /home/users/seyit/mpi/mpich2/lib -lmpich >>> ipo: warning #11043: unresolved H5Fclose >>> Referenced in io_h5file_interface.o >>> ipo: warning #11043: unresolved H5check_version >>> Referenced in io_h5file_interface.o >>> ipo: warning #11043: unresolved H5Fopen >>> Referenced in io_h5file_interface.o >>> ipo: warning #11043: unresolved H5Fcreate >>> Referenced in io_h5file_interface.o >>> ipo: warning #11043: unresolved H5Dopen >>> Referenced in io_h5read_bflags.o >>> Referenced in io_h5read_blk_particle_info.o >>> Referenced in io_h5read_blksize.o >>> Referenced in io_h5read_bndbox.o >>> Referenced in io_h5read_coords.o >>> Referenced in io_h5read_generic_int_arr.o >>> Referenced in io_h5read_generic_real_arr.o >>> Referenced in io_h5read_gid.o >>> Referenced in io_h5read_lists.o >>> Referenced in io_h5read_localnp.o >>> Referenced in io_h5read_lrefine.o >>> Referenced in io_h5read_nodetype.o >>> Referenced in io_h5read_particles.o >>> Referenced in io_h5read_unknowns.o >>> Referenced in io_h5read_which_child.o >>> Referenced in io_h5write_bflags.o >>> Referenced in io_h5write_blk_particle_info.o >>> Referenced in io_h5write_blksize.o >>> ... >>> ... >>> ... etc. >>> ... etc. >>> ... >>> ... >>> amr_initialize.F90(734): (col. 9) remark: LOOP WAS VECTORIZED. >>> amr_initialize.F90(735): (col. 9) remark: FUSED LOOP WAS >>> VECTORIZED. >>> amr_initialize.F90(737): (col. 9) remark: FUSED LOOP WAS >>> VECTORIZED. >>> amr_initialize.F90(741): (col. 9) remark: LOOP WAS VECTORIZED. >>> amr_initialize.F90(742): (col. 9) remark: LOOP WAS VECTORIZED. >>> amr_initialize.F90(838): (col. 7) remark: LOOP WAS VECTORIZED. >>> amr_initialize.F90(839): (col. 7) remark: LOOP WAS VECTORIZED. >>> gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS >>> VECTORIZED. >>> gr_initParameshArrays.F90(78): (col. 12) remark: LOOP WAS >>> VECTORIZED. >>> Grid_dump.F90(156): (col. 11) remark: LOOP WAS VECTORIZED. >>> PhysicalConstants_init.F90(127): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(130): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(133): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(136): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(139): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(142): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(145): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(148): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(151): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(154): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(157): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(160): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(165): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(167): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> PhysicalConstants_init.F90(169): (col. 8) remark: BLOCK WAS >>> VECTORIZED. >>> Grid_init.F90(280): (col. 3) remark: LOOP WAS VECTORIZED. >>> Grid_init.F90(375): (col. 3) remark: LOOP WAS VECTORIZED. >>> Grid_init.F90(385): (col. 6) remark: LOOP WAS VECTORIZED. >>> Particles_init.F90(108): (col. 3) remark: LOOP WAS VECTORIZED. >>> Particles_init.F90(135): (col. 3) remark: LOOP WAS VECTORIZED. >>> Particles_init.F90(182): (col. 6) remark: LOOP WAS VECTORIZED. >>> Grid_initDomain.F90(96): (col. 11) remark: LOOP WAS VECTORIZED. >>> Grid_initDomain.F90(114): (col. 20) remark: LOOP WAS VECTORIZED. >>> Grid_initDomain.F90(117): (col. 12) remark: FUSED LOOP WAS >>> VECTORIZED. >>> Grid_initDomain.F90(124): (col. 17) remark: LOOP WAS VECTORIZED. >>> Grid_initDomain.F90(133): (col. 17) remark: LOOP WAS VECTORIZED. >>> Grid_initDomain.F90(136): (col. 14) remark: LOOP WAS VECTORIZED. >>> Grid_initDomain.F90(171): (col. 12) remark: FUSED LOOP WAS >>> VECTORIZED. >>> Grid_initDomain.F90(189): (col. 14) remark: LOOP WAS VECTORIZED. >>> Driver_verifyInitDt.F90(98): (col. 14) remark: LOOP WAS VECTORIZED. >>> CosmologicalFunctions.F90(611): (col. 6) remark: LOOP WAS >>> VECTORIZED. >>> CosmologicalFunctions.F90(618): (col. 6) remark: LOOP WAS >>> VECTORIZED. >>> ld: skipping incompatible >>> /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.so when searching >>> for -lhdf5 >>> ld: skipping incompatible >>> /home/users/seyit/Libraries/Hdf5-166/lib/libhdf5.a when searching >>> for -lhdf5 >>> ld: cannot find -lhdf5 >>> make: *** [flash3] Error 1 >>> >>> >> >> >> From seyit at astro.rug.nl Wed Jun 4 11:38:06 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Wed, 04 Jun 2008 18:38:06 +0200 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <2467fdc0806031010p22ed2a2bwb7bf9d4497af5d95@mail.gmail.com> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> <2467fdc0806031010p22ed2a2bwb7bf9d4497af5d95@mail.gmail.com> Message-ID: <4846C4EE.4040204@astro.rug.nl> Hi Nathan, -debug (meaning without -fast) results in the same segmentation fault. This new compiler gives me a headache. Seyit. Nathan Hearn wrote: > Hi Seyit, > > Looking at the compiler output that you showed, I don't see any > warnings. The "remark" statements that you see are just the Intel > compiler's way of declaring that it produced vectorized (SSE2+) code > for some of the loops. (The compiler is apparently very happy when > this happens...) But yes, there is certainly a problem at runtime. > > I noticed that you are using fairly aggressive optimizations > (i.e., the "-fast -ipo" flags in FFLAGS_OPT). Have you tested the > code without optimizations? (Running setup with the -debug flag will > result in the FFLAGS_DEBUG options being used instead of FFLAGS_OPT.) > > > - Nathan > > > > On Tue, Jun 3, 2008 at 9:56 AM, Seyit Hocuk wrote: > >> Hi, >> >> Putting the correct HDF5 path solved only part of the problem. I still have >> a lot of warnings and the simulation does not start, giving the error below, >> even though making ends with success. Both for FLASH2.5 and for FLASH3.0. >> >> Regards, >> Seyit. >> From tomek at scs.fsu.edu Wed Jun 4 11:53:29 2008 From: tomek at scs.fsu.edu (Tomasz Plewa) Date: Wed, 04 Jun 2008 12:53:29 -0400 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <4846C4EE.4040204@astro.rug.nl> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> <2467fdc0806031010p22ed2a2bwb7bf9d4497af5d95@mail.gmail.com> <4846C4EE.4040204@astro.rug.nl> Message-ID: <20080604125329.pfrhkgpsw0sg8kw0@webmail.scs.fsu.edu> Seyit - The compiler works fine, at least for me and at least the latest two minor versions. I have seen the library incompatibility problem before, solved it, and happily forgot what exactly it was. But my vague recollection is that I messed up my enviornment, possibly used different mpich installations. Have you compiled hdf5 with mpich2? Tomek -- School of Computational Science, DSL 443 ph: 850.644.1959 Florida State University fax: 850.644.0098 Tallahassee, FL 32306 web: people.scs.fsu.edu/~tomek/ -- Seyit Hocuk wrote: > Hi Nathan, > > -debug (meaning without -fast) results in the same segmentation fault. > This new compiler gives me a headache. > > Seyit. > > > > > Nathan Hearn wrote: >> Hi Seyit, >> >> Looking at the compiler output that you showed, I don't see any >> warnings. The "remark" statements that you see are just the Intel >> compiler's way of declaring that it produced vectorized (SSE2+) code >> for some of the loops. (The compiler is apparently very happy when >> this happens...) But yes, there is certainly a problem at runtime. >> >> I noticed that you are using fairly aggressive optimizations >> (i.e., the "-fast -ipo" flags in FFLAGS_OPT). Have you tested the >> code without optimizations? (Running setup with the -debug flag will >> result in the FFLAGS_DEBUG options being used instead of FFLAGS_OPT.) >> >> >> - Nathan >> >> >> >> On Tue, Jun 3, 2008 at 9:56 AM, Seyit Hocuk wrote: >> >>> Hi, >>> >>> Putting the correct HDF5 path solved only part of the problem. I still have >>> a lot of warnings and the simulation does not start, giving the >>> error below, >>> even though making ends with success. Both for FLASH2.5 and for FLASH3.0. >>> >>> Regards, >>> Seyit. >>> > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From cdaley at flash.uchicago.edu Wed Jun 4 12:14:02 2008 From: cdaley at flash.uchicago.edu (Chris Daley) Date: Wed, 04 Jun 2008 12:14:02 -0500 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <4846C4EE.4040204@astro.rug.nl> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> <2467fdc0806031010p22ed2a2bwb7bf9d4497af5d95@mail.gmail.com> <4846C4EE.4040204@astro.rug.nl> Message-ID: <4846CD5A.7090007@flash.uchicago.edu> Hi Seyit, Is the failure happening when you run using one processor also? For one processor, an easy way to determine which line is causing the crash is to use gdb. From console type: gdb flash3 Run the code by typing: r When code crashes type: bt This generates a stack backtrace which, now we have compiled in 'debug' mode, will tell you where the problem occurred with line level detail. (For parallel debugging, type: mpirun -np x -gdb flash3). Or, if you have a core file type: gdb -c corefile flash3 Once again type: bt Finally, please ensure that FFLAGS_DEBUG in Makefile.h includes the -g flag. This is what gives us the line level detail. Regards, Chris Seyit Hocuk wrote: > Hi Nathan, > > -debug (meaning without -fast) results in the same segmentation fault. > This new compiler gives me a headache. > > Seyit. > > > > > Nathan Hearn wrote: >> Hi Seyit, >> >> Looking at the compiler output that you showed, I don't see any >> warnings. The "remark" statements that you see are just the Intel >> compiler's way of declaring that it produced vectorized (SSE2+) code >> for some of the loops. (The compiler is apparently very happy when >> this happens...) But yes, there is certainly a problem at runtime. >> >> I noticed that you are using fairly aggressive optimizations >> (i.e., the "-fast -ipo" flags in FFLAGS_OPT). Have you tested the >> code without optimizations? (Running setup with the -debug flag will >> result in the FFLAGS_DEBUG options being used instead of FFLAGS_OPT.) >> >> >> - Nathan >> >> >> >> On Tue, Jun 3, 2008 at 9:56 AM, Seyit Hocuk wrote: >> >>> Hi, >>> >>> Putting the correct HDF5 path solved only part of the problem. I >>> still have >>> a lot of warnings and the simulation does not start, giving the >>> error below, >>> even though making ends with success. Both for FLASH2.5 and for >>> FLASH3.0. >>> >>> Regards, >>> Seyit. >>> From seyit at astro.rug.nl Wed Jun 4 13:29:49 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Wed, 04 Jun 2008 20:29:49 +0200 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <4846CD5A.7090007@flash.uchicago.edu> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> <2467fdc0806031010p22ed2a2bwb7bf9d4497af5d95@mail.gmail.com> <4846C4EE.4040204@astro.rug.nl> <4846CD5A.7090007@flash.uchicago.edu> Message-ID: <4846DF1D.7060705@astro.rug.nl> Hi Chris, Tomek Tomek, I was thinking the same thing. Though I tried with different mpich(2) versions. Same problem. Maybe I need to reinstall Mpich2 completely again. I thought the same thing, but should it not give a problem while compiling then. Chris, I run 1 proc. I haven't tried with multi procs. See Below for gdb output. FFLAGS_DEBUG = -c -r8 -i4 -g -I $(MPI_PATH)/include (-g included) seyit at si01:~/FLASH3.0/object$ gdb flash3 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /home/users/seyit/FLASH3.0/object/flash3 [Thread debugging using libthread_db enabled] [New Thread 47309188393856 (LWP 6207)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47309188393856 (LWP 6207)] 0x00002b07062edf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0 (gdb) bt #0 0x00002b07062edf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0 #1 0x00002b07062f031f in PMPI_Comm_rank () from /usr/lib/libhdf5-1.6.5.so.0 #2 0x00000000005f0c3b in pmpi_comm_rank__ () #3 0x000000000040bec7 in driver_initparallel (mype=0, numprocs=0) at Driver_initParallel.F90:39 #4 0x000000000040b515 in driver_initflash () at Driver_initFlash.F90:84 #5 0x00000000004108fe in flash () at Flash.F90:36 (gdb) FFLAGS_DEBUG = -c -r8 -i4 -I $(MPI_PATH)/include (no -g) seyit at si01:~/FLASH3.0/object$ gdb flash3 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /home/users/seyit/FLASH3.0/object/flash3 [Thread debugging using libthread_db enabled] [New Thread 47644112931712 (LWP 19960)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47644112931712 (LWP 19960)] 0x00002b55013dbf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0 (gdb) bt #0 0x00002b55013dbf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0 #1 0x00002b55013de31f in PMPI_Comm_rank () from /usr/lib/libhdf5-1.6.5.so.0 #2 0x000000000055da6b in pmpi_comm_rank__ () #3 0x00000000004091d7 in driver_initparallel_ () #4 0x0000000000408af7 in driver_initflash_ () #5 0x000000000040d55d in MAIN__ () Chris Daley wrote: > Hi Seyit, > > Is the failure happening when you run using one processor also? > > For one processor, an easy way to determine which line is causing the > crash is to use gdb. > > From console type: gdb flash3 > Run the code by typing: r > When code crashes type: bt > This generates a stack backtrace which, now we have compiled in > 'debug' mode, > will tell you where the problem occurred with line level detail. > > (For parallel debugging, type: mpirun -np x -gdb flash3). > > Or, if you have a core file type: gdb -c corefile flash3 > Once again type: bt > > Finally, please ensure that FFLAGS_DEBUG in Makefile.h includes the -g > flag. This > is what gives us the line level detail. > > Regards, > Chris > > > Seyit Hocuk wrote: >> Hi Nathan, >> >> -debug (meaning without -fast) results in the same segmentation >> fault. This new compiler gives me a headache. >> >> Seyit. >> >> >> >> >> Nathan Hearn wrote: >>> Hi Seyit, >>> >>> Looking at the compiler output that you showed, I don't see any >>> warnings. The "remark" statements that you see are just the Intel >>> compiler's way of declaring that it produced vectorized (SSE2+) code >>> for some of the loops. (The compiler is apparently very happy when >>> this happens...) But yes, there is certainly a problem at runtime. >>> >>> I noticed that you are using fairly aggressive optimizations >>> (i.e., the "-fast -ipo" flags in FFLAGS_OPT). Have you tested the >>> code without optimizations? (Running setup with the -debug flag will >>> result in the FFLAGS_DEBUG options being used instead of FFLAGS_OPT.) >>> >>> >>> - Nathan >>> >>> >>> >>> On Tue, Jun 3, 2008 at 9:56 AM, Seyit Hocuk wrote: >>> >>>> Hi, >>>> >>>> Putting the correct HDF5 path solved only part of the problem. I >>>> still have >>>> a lot of warnings and the simulation does not start, giving the >>>> error below, >>>> even though making ends with success. Both for FLASH2.5 and for >>>> FLASH3.0. >>>> >>>> Regards, >>>> Seyit. >>>> From nhearn at uchicago.edu Wed Jun 4 13:43:21 2008 From: nhearn at uchicago.edu (Nathan Hearn) Date: Wed, 4 Jun 2008 13:43:21 -0500 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <4846DF1D.7060705@astro.rug.nl> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> <2467fdc0806031010p22ed2a2bwb7bf9d4497af5d95@mail.gmail.com> <4846C4EE.4040204@astro.rug.nl> <4846CD5A.7090007@flash.uchicago.edu> <4846DF1D.7060705@astro.rug.nl> Message-ID: <2467fdc0806041143w1d7c0826ve8946d697dff3a22@mail.gmail.com> Hi Seyit, Is it possible that HDF5 needs to be recompiled for this version of MPI? (Chris noticed that these MPI routines are being called from within the HDF5 library.) Short of that, there are two things you could try: 1. Make sure that the MPI setup is currently working. (There may have been a change to the system that is causing a problem.) Running a simple, parallel "hello world"-type program may be sufficient. 2. Try running Flash with a serial version of HDF5. - Nathan On Wed, Jun 4, 2008 at 1:29 PM, Seyit Hocuk wrote: > Hi Chris, Tomek > > > Tomek, I was thinking the same thing. Though I tried with different mpich(2) > versions. Same problem. Maybe I need to reinstall Mpich2 completely again. I > thought the same thing, but should it not give a problem while compiling > then. > > > Chris, I run 1 proc. I haven't tried with multi procs. See Below for gdb > output. From lusk at mcs.anl.gov Wed Jun 4 13:43:44 2008 From: lusk at mcs.anl.gov (Rusty Lusk) Date: Wed, 4 Jun 2008 13:43:44 -0500 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <4846DF1D.7060705@astro.rug.nl> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> <2467fdc0806031010p22ed2a2bwb7bf9d4497af5d95@mail.gmail.com> <4846C4EE.4040204@astro.rug.nl> <4846CD5A.7090007@flash.uchicago.edu> <4846DF1D.7060705@astro.rug.nl> Message-ID: <940EFC01-575C-4E99-B54A-C17FDC66C5A3@mcs.anl.gov> Just in case, did you call MPI_Init_thread? Rusty On Wednesday,Jun 4, 2008, at 1:29 PM, Seyit Hocuk wrote: > Hi Chris, Tomek > > > Tomek, I was thinking the same thing. Though I tried with different > mpich(2) versions. Same problem. Maybe I need to reinstall Mpich2 > completely again. I thought the same thing, but should it not give > a problem while compiling then. > > > Chris, I run 1 proc. I haven't tried with multi procs. See Below for > gdb output. > > > > > FFLAGS_DEBUG = -c -r8 -i4 -g -I $(MPI_PATH)/include > (-g included) > > seyit at si01:~/FLASH3.0/object$ gdb flash3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "x86_64-linux-gnu"... > Using host libthread_db library "/lib/libthread_db.so.1". > (gdb) r > Starting program: /home/users/seyit/FLASH3.0/object/flash3 > [Thread debugging using libthread_db enabled] > [New Thread 47309188393856 (LWP 6207)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 47309188393856 (LWP 6207)] > 0x00002b07062edf08 in MPIR_ToPointer () from /usr/lib/ > libhdf5-1.6.5.so.0 > (gdb) bt > #0 0x00002b07062edf08 in MPIR_ToPointer () from /usr/lib/ > libhdf5-1.6.5.so.0 > #1 0x00002b07062f031f in PMPI_Comm_rank () from /usr/lib/ > libhdf5-1.6.5.so.0 > #2 0x00000000005f0c3b in pmpi_comm_rank__ () > #3 0x000000000040bec7 in driver_initparallel (mype=0, numprocs=0) > at Driver_initParallel.F90:39 > #4 0x000000000040b515 in driver_initflash () at > Driver_initFlash.F90:84 > #5 0x00000000004108fe in flash () at Flash.F90:36 > (gdb) > > > > > > > FFLAGS_DEBUG = -c -r8 -i4 -I $(MPI_PATH)/include > (no -g) > > seyit at si01:~/FLASH3.0/object$ gdb flash3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "x86_64-linux-gnu"... > Using host libthread_db library "/lib/libthread_db.so.1". > (gdb) r > Starting program: /home/users/seyit/FLASH3.0/object/flash3 > [Thread debugging using libthread_db enabled] > [New Thread 47644112931712 (LWP 19960)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 47644112931712 (LWP 19960)] > 0x00002b55013dbf08 in MPIR_ToPointer () from /usr/lib/ > libhdf5-1.6.5.so.0 > (gdb) bt > #0 0x00002b55013dbf08 in MPIR_ToPointer () from /usr/lib/ > libhdf5-1.6.5.so.0 > #1 0x00002b55013de31f in PMPI_Comm_rank () from /usr/lib/ > libhdf5-1.6.5.so.0 > #2 0x000000000055da6b in pmpi_comm_rank__ () > #3 0x00000000004091d7 in driver_initparallel_ () > #4 0x0000000000408af7 in driver_initflash_ () > #5 0x000000000040d55d in MAIN__ () > > > > > Chris Daley wrote: >> Hi Seyit, >> >> Is the failure happening when you run using one processor also? >> >> For one processor, an easy way to determine which line is causing >> the crash is to use gdb. >> >> From console type: gdb flash3 >> Run the code by typing: r >> When code crashes type: bt >> This generates a stack backtrace which, now we have compiled in >> 'debug' mode, >> will tell you where the problem occurred with line level detail. >> >> (For parallel debugging, type: mpirun -np x -gdb flash3). >> >> Or, if you have a core file type: gdb -c corefile flash3 >> Once again type: bt >> >> Finally, please ensure that FFLAGS_DEBUG in Makefile.h includes the >> -g flag. This >> is what gives us the line level detail. >> >> Regards, >> Chris >> >> >> Seyit Hocuk wrote: >>> Hi Nathan, >>> >>> -debug (meaning without -fast) results in the same segmentation >>> fault. This new compiler gives me a headache. >>> >>> Seyit. >>> >>> >>> >>> >>> Nathan Hearn wrote: >>>> Hi Seyit, >>>> >>>> Looking at the compiler output that you showed, I don't see any >>>> warnings. The "remark" statements that you see are just the Intel >>>> compiler's way of declaring that it produced vectorized (SSE2+) >>>> code >>>> for some of the loops. (The compiler is apparently very happy when >>>> this happens...) But yes, there is certainly a problem at runtime. >>>> >>>> I noticed that you are using fairly aggressive optimizations >>>> (i.e., the "-fast -ipo" flags in FFLAGS_OPT). Have you tested the >>>> code without optimizations? (Running setup with the -debug flag >>>> will >>>> result in the FFLAGS_DEBUG options being used instead of >>>> FFLAGS_OPT.) >>>> >>>> >>>> - Nathan >>>> >>>> >>>> >>>> On Tue, Jun 3, 2008 at 9:56 AM, Seyit Hocuk >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Putting the correct HDF5 path solved only part of the problem. I >>>>> still have >>>>> a lot of warnings and the simulation does not start, giving the >>>>> error below, >>>>> even though making ends with success. Both for FLASH2.5 and for >>>>> FLASH3.0. >>>>> >>>>> Regards, >>>>> Seyit. >>>>> > From tomek at scs.fsu.edu Wed Jun 4 13:44:30 2008 From: tomek at scs.fsu.edu (Tomasz Plewa) Date: Wed, 04 Jun 2008 14:44:30 -0400 Subject: [FLASH-USERS] Problem with Compiling Flash3.0 In-Reply-To: <4846DF1D.7060705@astro.rug.nl> References: <48441DC4.9050701@astro.rug.nl> <5b942a610806020923m20556b61pa7c99be31cc46562@mail.gmail.com> <48455BAA.8050405@astro.rug.nl> <2467fdc0806031010p22ed2a2bwb7bf9d4497af5d95@mail.gmail.com> <4846C4EE.4040204@astro.rug.nl> <4846CD5A.7090007@flash.uchicago.edu> <4846DF1D.7060705@astro.rug.nl> Message-ID: <20080604144430.h5v67w0v9cw488ks@webmail.scs.fsu.edu> Seyit - I would suggest a clean installation starting with reviewing your environment. Once your environment is clean of references to old compilers, etc., get the new compiler in, then mpich, little guys like zlib and/or szip, and finally hdf5. And since you are at it, you may want to install a serial hdf5 version as well. The best if you do it in one sequence. Tomek -- School of Computational Science, DSL 443 ph: 850.644.1959 Florida State University fax: 850.644.0098 Tallahassee, FL 32306 web: people.scs.fsu.edu/~tomek/ -- Seyit Hocuk wrote: > Hi Chris, Tomek > > > Tomek, I was thinking the same thing. Though I tried with different > mpich(2) versions. Same problem. Maybe I need to reinstall Mpich2 > completely again. I thought the same thing, but should it not give a > problem while compiling then. > > > Chris, I run 1 proc. I haven't tried with multi procs. See Below for > gdb output. > > > > > FFLAGS_DEBUG = -c -r8 -i4 -g -I $(MPI_PATH)/include > (-g included) > > seyit at si01:~/FLASH3.0/object$ gdb flash3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu"... > Using host libthread_db library "/lib/libthread_db.so.1". > (gdb) r > Starting program: /home/users/seyit/FLASH3.0/object/flash3 > [Thread debugging using libthread_db enabled] > [New Thread 47309188393856 (LWP 6207)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 47309188393856 (LWP 6207)] > 0x00002b07062edf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0 > (gdb) bt > #0 0x00002b07062edf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0 > #1 0x00002b07062f031f in PMPI_Comm_rank () from /usr/lib/libhdf5-1.6.5.so.0 > #2 0x00000000005f0c3b in pmpi_comm_rank__ () > #3 0x000000000040bec7 in driver_initparallel (mype=0, numprocs=0) at > Driver_initParallel.F90:39 > #4 0x000000000040b515 in driver_initflash () at Driver_initFlash.F90:84 > #5 0x00000000004108fe in flash () at Flash.F90:36 > (gdb) > > > > > > > FFLAGS_DEBUG = -c -r8 -i4 -I $(MPI_PATH)/include > (no -g) > > seyit at si01:~/FLASH3.0/object$ gdb flash3 > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu"... > Using host libthread_db library "/lib/libthread_db.so.1". > (gdb) r > Starting program: /home/users/seyit/FLASH3.0/object/flash3 > [Thread debugging using libthread_db enabled] > [New Thread 47644112931712 (LWP 19960)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 47644112931712 (LWP 19960)] > 0x00002b55013dbf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0 > (gdb) bt > #0 0x00002b55013dbf08 in MPIR_ToPointer () from /usr/lib/libhdf5-1.6.5.so.0 > #1 0x00002b55013de31f in PMPI_Comm_rank () from /usr/lib/libhdf5-1.6.5.so.0 > #2 0x000000000055da6b in pmpi_comm_rank__ () > #3 0x00000000004091d7 in driver_initparallel_ () > #4 0x0000000000408af7 in driver_initflash_ () > #5 0x000000000040d55d in MAIN__ () > > > > > Chris Daley wrote: >> Hi Seyit, >> >> Is the failure happening when you run using one processor also? >> >> For one processor, an easy way to determine which line is causing >> the crash is to use gdb. >> >> From console type: gdb flash3 >> Run the code by typing: r >> When code crashes type: bt >> This generates a stack backtrace which, now we have compiled in >> 'debug' mode, >> will tell you where the problem occurred with line level detail. >> >> (For parallel debugging, type: mpirun -np x -gdb flash3). >> >> Or, if you have a core file type: gdb -c corefile flash3 >> Once again type: bt >> >> Finally, please ensure that FFLAGS_DEBUG in Makefile.h includes the >> -g flag. This >> is what gives us the line level detail. >> >> Regards, >> Chris >> >> >> Seyit Hocuk wrote: >>> Hi Nathan, >>> >>> -debug (meaning without -fast) results in the same segmentation >>> fault. This new compiler gives me a headache. >>> >>> Seyit. >>> >>> >>> >>> >>> Nathan Hearn wrote: >>>> Hi Seyit, >>>> >>>> Looking at the compiler output that you showed, I don't see any >>>> warnings. The "remark" statements that you see are just the Intel >>>> compiler's way of declaring that it produced vectorized (SSE2+) code >>>> for some of the loops. (The compiler is apparently very happy when >>>> this happens...) But yes, there is certainly a problem at runtime. >>>> >>>> I noticed that you are using fairly aggressive optimizations >>>> (i.e., the "-fast -ipo" flags in FFLAGS_OPT). Have you tested the >>>> code without optimizations? (Running setup with the -debug flag will >>>> result in the FFLAGS_DEBUG options being used instead of FFLAGS_OPT.) >>>> >>>> >>>> - Nathan >>>> >>>> >>>> >>>> On Tue, Jun 3, 2008 at 9:56 AM, Seyit Hocuk wrote: >>>> >>>>> Hi, >>>>> >>>>> Putting the correct HDF5 path solved only part of the problem. I >>>>> still have >>>>> a lot of warnings and the simulation does not start, giving the >>>>> error below, >>>>> even though making ends with success. Both for FLASH2.5 and for FLASH3.0. >>>>> >>>>> Regards, >>>>> Seyit. >>>>> > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From bernalcg at astroscu.unam.mx Tue Jun 10 20:49:33 2008 From: bernalcg at astroscu.unam.mx (Giovanny Bernal) Date: Tue, 10 Jun 2008 20:49:33 -0500 Subject: [FLASH-USERS] Gravity PlanePar Message-ID: <117EE311-2CBD-4067-8B8C-BF731D1EC41B@astroscu.unam.mx> Hi people, I want to run a simulation using the gravity PlanePar unit, but when I compile my setup the error is... ________ fortcom: Error: Gravity_accelOneRow.F90, line 127: This name does not have a type, and must have an explicit type. [J] call grv_accelOneZone(xCenter (i), yCenter(j), zCenter(k), gc) ---------------------------------------------------^ fortcom: Error: Gravity_accelOneRow.F90, line 127: This name does not have a type, and must have an explicit type. [K] call grv_accelOneZone(xCenter (i), yCenter(j), zCenter(k), gc) ---------------------------------------------------------------^ fortcom: Error: Gravity_accelOneRow.F90, line 148: An allocate/ deallocate object must have the ALLOCATABLE or POINTER attribute. [XCENTER] deallocate(xCenter) -------------^ fortcom: Error: Gravity_accelOneRow.F90, line 149: An allocate/ deallocate object must have the ALLOCATABLE or POINTER attribute. [XLEFT] deallocate(xLeft) -------------^ fortcom: Error: Gravity_accelOneRow.F90, line 150: An allocate/ deallocate object must have the ALLOCATABLE or POINTER attribute. [XRIGHT] deallocate(xRight) -------------^ fortcom: Error: Gravity_accelOneRow.F90, line 151: An allocate/ deallocate object must have the ALLOCATABLE or POINTER attribute. [YCENTER] deallocate(yCenter) -------------^ fortcom: Error: Gravity_accelOneRow.F90, line 152: An allocate/ deallocate object must have the ALLOCATABLE or POINTER attribute. [YLEFT] deallocate(yLeft) -------------^ fortcom: Error: Gravity_accelOneRow.F90, line 153: An allocate/ deallocate object must have the ALLOCATABLE or POINTER attribute. [YRIGHT] deallocate(yRight) -------------^ fortcom: Error: Gravity_accelOneRow.F90, line 154: An allocate/ deallocate object must have the ALLOCATABLE or POINTER attribute. [ZCENTER] deallocate(zCenter) -------------^ fortcom: Error: Gravity_accelOneRow.F90, line 155: An allocate/ deallocate object must have the ALLOCATABLE or POINTER attribute. [ZLEFT] deallocate(zLeft) -------------^ fortcom: Error: Gravity_accelOneRow.F90, line 156: An allocate/ deallocate object must have the ALLOCATABLE or POINTER attribute. [ZRIGHT] deallocate(zRight) -------------^ compilation aborted for Gravity_accelOneRow.F90 (code 1) make: *** [Gravity_accelOneRow.o] Error 1 ________ the [J] & [K] values are easy solved because I see that in the "Gravity_accelOneRow.F90" the line 70 is: integer :: i and should be: integer :: i,j,k but the allocate/deallocate objects, I see that are here... any idea??? very thaks in advanced From dubey at flash.uchicago.edu Wed Jun 11 09:56:58 2008 From: dubey at flash.uchicago.edu (Anshu Dubey) Date: Wed, 11 Jun 2008 09:56:58 -0500 Subject: [FLASH-USERS] Gravity PlanePar In-Reply-To: <117EE311-2CBD-4067-8B8C-BF731D1EC41B@astroscu.unam.mx> References: <117EE311-2CBD-4067-8B8C-BF731D1EC41B@astroscu.unam.mx> Message-ID: <5b942a610806110756n7584eda7nb5d4faa3130258ad@mail.gmail.com> You have found us a couple of bugs here. The block of deallocates should have an "#ifndef FIXEDBLOCKSIZE; #endif" around it. The arrays should be allocated and deallocated only in nonfixedblocksize mode. In the next email I will include the modified file. On Tue, Jun 10, 2008 at 8:49 PM, Giovanny Bernal wrote: > Hi people, > > I want to run a simulation using the gravity PlanePar unit, but when I > compile my setup the error is... > > ________ > fortcom: Error: Gravity_accelOneRow.F90, line 127: This name does not have > a type, and must have an explicit type. [J] > call grv_accelOneZone(xCenter (i), yCenter(j), zCenter(k), gc) > ---------------------------------------------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 127: This name does not have > a type, and must have an explicit type. [K] > call grv_accelOneZone(xCenter (i), yCenter(j), zCenter(k), gc) > ---------------------------------------------------------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 148: An allocate/deallocate > object must have the ALLOCATABLE or POINTER attribute. [XCENTER] > deallocate(xCenter) > -------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 149: An allocate/deallocate > object must have the ALLOCATABLE or POINTER attribute. [XLEFT] > deallocate(xLeft) > -------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 150: An allocate/deallocate > object must have the ALLOCATABLE or POINTER attribute. [XRIGHT] > deallocate(xRight) > -------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 151: An allocate/deallocate > object must have the ALLOCATABLE or POINTER attribute. [YCENTER] > deallocate(yCenter) > -------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 152: An allocate/deallocate > object must have the ALLOCATABLE or POINTER attribute. [YLEFT] > deallocate(yLeft) > -------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 153: An allocate/deallocate > object must have the ALLOCATABLE or POINTER attribute. [YRIGHT] > deallocate(yRight) > -------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 154: An allocate/deallocate > object must have the ALLOCATABLE or POINTER attribute. [ZCENTER] > deallocate(zCenter) > -------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 155: An allocate/deallocate > object must have the ALLOCATABLE or POINTER attribute. [ZLEFT] > deallocate(zLeft) > -------------^ > fortcom: Error: Gravity_accelOneRow.F90, line 156: An allocate/deallocate > object must have the ALLOCATABLE or POINTER attribute. [ZRIGHT] > deallocate(zRight) > -------------^ > compilation aborted for Gravity_accelOneRow.F90 (code 1) > make: *** [Gravity_accelOneRow.o] Error 1 > ________ > > the [J] & [K] values are easy solved because I see that in the > "Gravity_accelOneRow.F90" the line 70 is: > integer :: i > and should be: > integer :: i,j,k > > but the allocate/deallocate objects, I see that are here... any idea??? > > very thaks in advanced > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080611/4319550d/attachment.html From mateuszr at umich.edu Fri Jun 13 12:51:12 2008 From: mateuszr at umich.edu (mateuszr at umich.edu) Date: Fri, 13 Jun 2008 13:51:12 -0400 Subject: [FLASH-USERS] hse bndry conditions Message-ID: <20080613135112.11780vk96dwickas@web.mail.umich.edu> Hi All, a super quick question about the hydrostatic boundary conditions. Are they compatabile with all physics modules ? In the Config file I have: REQUIRES Grid/GridBoundaryConditions/OneRow/Flash2HSE In flash.par I have: yl_boundary_type = "hydrostatic-f2+nvrefl" And in the log file I get: [DRIVER_ABORT] Driver_abort() called by PE 0 abort_message unsupported boundary condition on Lower Face The code works fine with "reflect" boundary conditions but hse would be more appropriate. thanks, Mateusz From klaus at flash.uchicago.edu Mon Jun 16 14:36:00 2008 From: klaus at flash.uchicago.edu (Klaus Weide) Date: Mon, 16 Jun 2008 14:36:00 -0500 (CDT) Subject: [FLASH-USERS] hse bndry conditions In-Reply-To: <20080613135112.11780vk96dwickas@web.mail.umich.edu> References: <20080613135112.11780vk96dwickas@web.mail.umich.edu> Message-ID: On Fri, 13 Jun 2008, mateuszr at umich.edu wrote: > a super quick question about the hydrostatic boundary conditions. > Are they compatabile with all physics modules ? > > In the Config file I have: > REQUIRES Grid/GridBoundaryConditions/OneRow/Flash2HSE > > In flash.par I have: > yl_boundary_type = "hydrostatic-f2+nvrefl" I have tried to reproduce your problem by adding those two lines to the Config and flash.par files, repectively, of a standard Sedov setup. I did not encounter your problem. Please provide more information about your setup. What gravity implementation are you using? In particular, the units included and any modified Config files would be useful. Can you provide the output of the following command in you object directory? ls -l Grid_apply*.F90 Grid_BC*.F90 gr_apply*.F90 gr_bc*.F90 Gravity*.F90 A caveat regarding the provided hydrostatic boundary conditions: these are ported from the default implementation in FLASH2. However, various setups in FLASH2 used their own implementations overriding the defaults. You should also check whether the algorithm used is appropriate for you or whether you should provide your own. Klaus Weide FLASH Center From latife at astro.rug.nl Wed Jun 18 04:46:53 2008 From: latife at astro.rug.nl (M.A. Latife) Date: Wed, 18 Jun 2008 11:46:53 +0200 Subject: [FLASH-USERS] ERROR: unable to allocate temp particle buffer Message-ID: <4858D98D.8080007@astro.rug.nl> Hi, Dear All, i am running simulation including Particles and gas. when i put more resolution like lrefine_min=5 and lrefine_max =8 and max blocks more than 2000 for 2-D i get the following error in log file. Can any body tell me why it is happening and what is the possible solution for it.i have checked separately for particles and gas for high resolution, both work fine. Best Regards Latif ./setup test -maxblocks=5000 -auto Following is out put written in log file 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated at 11:34.03 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=5 max=5 tot=5 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=4 max=4 tot=4 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated at 11:34.03 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=21 max=21 tot=21 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=16 max=16 tot=16 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated at 11:34.03 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=85 max=85 tot=85 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=64 max=64 tot=64 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated at 11:34.03 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=341 max=341 tot=341 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=256 max=256 tot=256 [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete [ 06-18-2008 11:34.04 ] message: [CHECKPOINT_WR] NOTE: will send 459 blocks per message. [ 06-18-2008 11:34.04 ] flash_abort: abort_flash() called by PE 0 [ 06-18-2008 11:34.04 ] abort_message: [CHECKPOINT_WR] ERROR: unable to allocate temp particle buffer From turcotte at apollo.ubishops.ca Wed Jun 18 13:31:48 2008 From: turcotte at apollo.ubishops.ca (turcotte) Date: Wed, 18 Jun 2008 14:31:48 -0400 (EDT) Subject: [FLASH-USERS] wrong ndim - compiler issues Message-ID: <200806181831.m5IIVmO17710@apollo.ubishops.ca> Hello all, I am having issues with Flash3.0 since a system "upgrade" on the computer on which it runs. The most recent one is that the "ndim" written out in the HDF5 files is not 1 or 2 depending on the problem but always 3. Using fidlr3.0, H5S_GET_SIMPLE_EXTENT_DIMS(dataspace) will give me a dims[0]=3 even for a 1-D or 2-D problem (for checkpoint and plotting files) I have looked around io_writedata.F90 but found all variables including NDIM to be reasonable. This happens if I run the sedov test with the -debug option or my own problem. So, has anyone had problems using the 64bit intel fortran compiler? flags to set or to avoid? And where exactly is the dimension written out to the chk or plt files? Sylvain 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 tangsk at astro.umass.edu Thu Jun 19 22:51:11 2008 From: tangsk at astro.umass.edu (Shikui Tang) Date: Thu, 19 Jun 2008 23:51:11 -0400 Subject: [FLASH-USERS] possible I/O functions in FLASH3? Message-ID: <485B292F.5070009@astro.umass.edu> Hi all, I am just wondering whether there are I/O interfaces in FLASH3 which are able to write out blocks with certain refinement level or within some specified regions ONLY? I look through the I/O module but did not find any. If somebody happens to have implemented them already. would you let me know? Thanks a lot! Bests, Shikui From richp at flash.uchicago.edu Fri Jun 20 11:06:34 2008 From: richp at flash.uchicago.edu (Paul M. Rich) Date: Fri, 20 Jun 2008 11:06:34 -0500 Subject: [FLASH-USERS] possible I/O functions in FLASH3? In-Reply-To: <485B292F.5070009@astro.umass.edu> References: <485B292F.5070009@astro.umass.edu> Message-ID: <485BD58A.4050609@flash.uchicago.edu> Shikui, At this point, there are no such interfaces in FLASH3. Usually when we have selected regions or selected particular refinement levels, we have done this in the post-processing of the run results. If you are just looking to visualize data at a particular refinement and/or in a particular region, the current version of VisIT is capable of selecting regions and I believe it is capable of selecting a particular refinement level. Paul Shikui Tang wrote: > Hi all, > > I am just wondering whether there are I/O interfaces in FLASH3 > which are able to write out blocks with certain refinement level or > within some specified regions ONLY? I look through the I/O module but > did not find any. If somebody happens to have implemented them > already. would you let me know? Thanks a lot! > > Bests, > Shikui From tomek at scs.fsu.edu Fri Jun 20 11:31:27 2008 From: tomek at scs.fsu.edu (Tomasz Plewa) Date: Fri, 20 Jun 2008 12:31:27 -0400 Subject: [FLASH-USERS] possible I/O functions in FLASH3? In-Reply-To: <485BD58A.4050609@flash.uchicago.edu> References: <485B292F.5070009@astro.umass.edu> <485BD58A.4050609@flash.uchicago.edu> Message-ID: <20080620123127.28f5yq6ls044wwg4@webmail.scs.fsu.edu> At the moment there is no support in VisIt for *downloading* data for particular physical or logical region of the computational box. Once the data are in, however, it can be decimated and sliced. Tomek -- School of Computational Science, DSL 443 ph: 850.644.1959 Florida State University fax: 850.644.0098 Tallahassee, FL 32306 web: people.scs.fsu.edu/~tomek/ -- Paul M. Rich wrote: > Shikui, > > At this point, there are no such interfaces in FLASH3. Usually when we > have selected regions or selected particular refinement levels, we have > done this in the post-processing of the run results. If you are just > looking to visualize data at a particular refinement and/or in a > particular region, the current version of VisIT is capable of selecting > regions and I believe it is capable of selecting a particular > refinement level. Paul > > Shikui Tang wrote: >> Hi all, >> >> I am just wondering whether there are I/O interfaces in FLASH3 >> which are able to write out blocks with certain refinement level or >> within some specified regions ONLY? I look through the I/O module >> but did not find any. If somebody happens to have implemented them >> already. would you let me know? Thanks a lot! >> >> Bests, >> Shikui > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From absefko at sandia.gov Fri Jun 20 17:00:06 2008 From: absefko at sandia.gov (A. B. Sefkow) Date: Fri, 20 Jun 2008 16:00:06 -0600 Subject: [FLASH-USERS] MRT question Message-ID: <485C2866.4060807@sandia.gov> Dear Flash Users, I am a new Flash user and became interested in the code in order to attempt a Magnetic Rayleigh Taylor (MRT) simulation. I'm still going through the provided examples and the manual in order to learn how to use the code, but so far it isn't obvious to me how one can specify magnetic fields and pressure *beyond* the initialization. In other words, would I need a circuit model to do this in Flash, or is there some way to tell the code how I want I(t) [Bx(t),By(t),Bz(t)] to evolve (say, at a boundary, and let it diffuse in)? Along those lines, can nonideal MHD parameters be set for different fluids? I essentially want to start really simple, say by just exchanging gravity for magnetics in a straight forward RT simulation. If anybody has a simple RT or MRT setup they would be willing to share in order to help a new user learn, I would be much indebted. Thanks, Adam From richp at flash.uchicago.edu Mon Jun 23 15:24:54 2008 From: richp at flash.uchicago.edu (Paul M. Rich) Date: Mon, 23 Jun 2008 15:24:54 -0500 Subject: [FLASH-USERS] ERROR: unable to allocate temp particle buffer In-Reply-To: <4858D98D.8080007@astro.rug.nl> References: <4858D98D.8080007@astro.rug.nl> Message-ID: <48600696.9070708@flash.uchicago.edu> Latif, What is your MaxParticlesPerProc? If this is too high, at a high resolution you can run out of memory to allocate from the heap. Does it work if you lower the MaxParticlesPerProc? Serial IO requires a secondary particle buffer to move data from the master pe to the other pe's on read-in. Also, about how much memory do you have per core on the machine you're trying this on? --Paul ------------------------------- ASC FLASH Center University of Chicago M.A. Latife wrote: > Hi, > Dear All, > i am running simulation including Particles and gas. when i put more > resolution like lrefine_min=5 and lrefine_max =8 and max blocks more > than 2000 for 2-D i get the following error in log file. Can any body > tell me why it is happening and what is the possible solution for it.i > have checked separately for particles and gas for high resolution, > both work fine. > Best Regards > Latif > > > ./setup test -maxblocks=5000 -auto > > Following is out put written in log file > > 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated at 11:34.03 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=5 > max=5 tot=5 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=4 > max=4 tot=4 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated > at 11:34.03 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=21 > max=21 tot=21 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=16 > max=16 tot=16 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated > at 11:34.03 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=85 > max=85 tot=85 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=64 > max=64 tot=64 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated > at 11:34.03 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=341 > max=341 tot=341 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=256 > max=256 tot=256 > [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete > [ 06-18-2008 11:34.04 ] message: [CHECKPOINT_WR] NOTE: will > send 459 blocks per message. > [ 06-18-2008 11:34.04 ] flash_abort: abort_flash() called by > PE 0 > [ 06-18-2008 11:34.04 ] abort_message: [CHECKPOINT_WR] ERROR: unable > to allocate temp particle buffer From richp at flash.uchicago.edu Mon Jun 23 15:30:04 2008 From: richp at flash.uchicago.edu (Paul M. Rich) Date: Mon, 23 Jun 2008 15:30:04 -0500 Subject: [FLASH-USERS] ERROR: unable to allocate temp particle buffer In-Reply-To: <48600696.9070708@flash.uchicago.edu> References: <4858D98D.8080007@astro.rug.nl> <48600696.9070708@flash.uchicago.edu> Message-ID: <486007CC.1070201@flash.uchicago.edu> I also should add that this temporary buffer is needed on write-out for essentially the same reason it is needed for read in in serial IO. --Paul ------------------------------- ASC FLASH Center University of Chicago Paul M. Rich wrote: > Latif, > > What is your MaxParticlesPerProc? If this is too high, at a high > resolution you can run out of memory to allocate from the heap. Does > it work if you lower the MaxParticlesPerProc? Serial IO requires a > secondary particle buffer to move data from the master pe to the > other pe's on read-in. Also, about how much memory do you have per > core on the machine you're trying this on? > > --Paul > ------------------------------- > ASC FLASH Center > University of Chicago > > M.A. Latife wrote: >> Hi, >> Dear All, >> i am running simulation including Particles and gas. when i put more >> resolution like lrefine_min=5 and lrefine_max =8 and max blocks >> more than 2000 for 2-D i get the following error in log file. Can any >> body tell me why it is happening and what is the possible solution >> for it.i have checked separately for particles and gas for high >> resolution, both work fine. >> Best Regards >> Latif >> >> >> ./setup test -maxblocks=5000 -auto >> >> Following is out put written in log file >> >> 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated at 11:34.03 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=5 >> max=5 tot=5 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=4 >> max=4 tot=4 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated >> at 11:34.03 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=21 >> max=21 tot=21 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=16 >> max=16 tot=16 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated >> at 11:34.03 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=85 >> max=85 tot=85 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=64 >> max=64 tot=64 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement initiated >> at 11:34.03 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks all: min=341 >> max=341 tot=341 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE] blocks valid: min=256 >> max=256 tot=256 >> [ 06-18-2008 11:34.03 ] [AMR_REFINE_DEREFINE]: refinement complete >> [ 06-18-2008 11:34.04 ] message: [CHECKPOINT_WR] NOTE: will >> send 459 blocks per message. >> [ 06-18-2008 11:34.04 ] flash_abort: abort_flash() called by >> PE 0 >> [ 06-18-2008 11:34.04 ] abort_message: [CHECKPOINT_WR] ERROR: unable >> to allocate temp particle buffer From latife at astro.rug.nl Tue Jun 24 10:06:07 2008 From: latife at astro.rug.nl (M.A. Latife) Date: Tue, 24 Jun 2008 17:06:07 +0200 Subject: [FLASH-USERS] value of variables at old time step Message-ID: <48610D5F.8000309@astro.rug.nl> Hi, Dear All, i want to know the old value of density and temperature( at previous time step) for every block . i don't know how to take these values from data base. i also want to know how can i take the values of variables for one block or for all blocks. can any body help me Thanks in Advance Cheers Latif From absefko at sandia.gov Tue Jun 24 18:05:02 2008 From: absefko at sandia.gov (A. B. Sefkow) Date: Tue, 24 Jun 2008 17:05:02 -0600 Subject: [FLASH-USERS] Reading HDF5 Flash3 output in Yorick? Message-ID: <48617D9E.1060801@sandia.gov> Hi, Has anyone had any luck installing the hdf5 package for the Yorick distribution, and analyzing Flash3 data in it? Regards, Adam From dubey at flash.uchicago.edu Wed Jun 25 09:17:59 2008 From: dubey at flash.uchicago.edu (Anshu Dubey) Date: Wed, 25 Jun 2008 09:17:59 -0500 Subject: [FLASH-USERS] value of variables at old time step In-Reply-To: <48610D5F.8000309@astro.rug.nl> References: <48610D5F.8000309@astro.rug.nl> Message-ID: <5b942a610806250717t7306bb35xa6f64359f781f431@mail.gmail.com> By default FLASH does not retain the values of previous time-step. Once the timestep calculation is finished, the current values overwrite the previous time-step. A simple way to keep values from the previous timestep around is to add two more variables to unk, say told, and dold, and just before overwriting the values into temp and dens, copy those values into these two variables. In FLASH3, you can also use scratch variables, but they will have consistent values only if there is no regridding between steps. The mechanisms for fetching data for a block are listed in the user's guide, as well as the online documentation for the FLASH3 API at http://flash.uchicago.edu/website/codesupport/robodoc-FLASH3. Look for functions "Grid_getBlkData" and "Grid_getBlkPtr". FLASH discourages you from getting the data for all the blocks at once, though this being FORTRAN, if you really want to, you can. But you must be very, very familiar with the code before playing with data at that internal a level. Anshu On Tue, Jun 24, 2008 at 10:06 AM, M.A. Latife wrote: > Hi, > Dear All, > i want to know the old value of density and temperature( at previous time > step) for every block . i don't know how to take these values from data > base. i also want to know how can i take the values of variables for one > block or for all blocks. > can any body help me > Thanks in Advance > Cheers > Latif > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080625/3e6aea66/attachment.html From seyit at astro.rug.nl Thu Jun 26 08:29:54 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Thu, 26 Jun 2008 15:29:54 +0200 Subject: [FLASH-USERS] Are shockwaves standard in Flash Message-ID: <486399D2.8040800@astro.rug.nl> Hi, A simple question: Are Shockwaves standard in Flash or do I have to do something in order to create/detect shocks? My simulations typically have velocities higher then the local sound speed, so I expect some shockwaves, but I don't think I have any in my results. Regards, Seyit From tomek at scs.fsu.edu Thu Jun 26 08:41:20 2008 From: tomek at scs.fsu.edu (Tomasz Plewa) Date: Thu, 26 Jun 2008 09:41:20 -0400 Subject: [FLASH-USERS] Are shockwaves standard in Flash In-Reply-To: <486399D2.8040800@astro.rug.nl> References: <486399D2.8040800@astro.rug.nl> Message-ID: <20080626094120.8lm0l3zn40o4c0sk@webmail.scs.fsu.edu> Seit - Shocks are automatically included and resolved in at least basic hydro solver, PPM. There is a module designed to detect multidimensional shocks: FLASH2: shock_detect.F90 FLASH3: Hydro_detectShock.F90 This module was directly adopted from Woodward & Porter's sPPM code. One dimensional shock detection is a part PPM (see Colella & Woodward paper; essentially look for pressure jumps of order of 0.3 associated with negative velocity divergence). Hope this helps. Best - Tomek -- Department of Scientific Computing, DSL 443 ph: 850.644.1959 Florida State University fax: 850.644.0098 Tallahassee, FL 32306 web: people.scs.fsu.edu/~tomek/ -- Seyit Hocuk wrote: > Hi, > > A simple question: Are Shockwaves standard in Flash or do I have to do > something in order to create/detect shocks? > My simulations typically have velocities higher then the local sound > speed, so I expect some shockwaves, but I don't think I have any in my > results. > > Regards, > Seyit > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From seyit at astro.rug.nl Thu Jun 26 09:04:20 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Thu, 26 Jun 2008 16:04:20 +0200 Subject: [FLASH-USERS] Are shockwaves standard in Flash In-Reply-To: <20080626094120.8lm0l3zn40o4c0sk@webmail.scs.fsu.edu> References: <486399D2.8040800@astro.rug.nl> <20080626094120.8lm0l3zn40o4c0sk@webmail.scs.fsu.edu> Message-ID: <4863A1E4.1040000@astro.rug.nl> Hi Adam and Tomek Yes I see in the hydro_sweep that the 1-d one is always included in the PPM. To get a more accurate shock detect, it says to include a multi dimensional one which you can do by setting that parameter to true. Thanks, for the quick replies. Seyit Tomasz Plewa wrote: > Seit - > > Shocks are automatically included and resolved in at least basic hydro > solver, PPM. > > There is a module designed to detect multidimensional shocks: > > FLASH2: shock_detect.F90 > FLASH3: Hydro_detectShock.F90 > > This module was directly adopted from Woodward & Porter's sPPM code. > > One dimensional shock detection is a part PPM (see Colella & Woodward > paper; essentially look for pressure jumps of order of 0.3 associated > with negative velocity divergence). > > Hope this helps. > > Best - > > Tomek