From miesch at ucar.edu Tue Apr 1 23:18:44 2008 From: miesch at ucar.edu (Mark Miesch) Date: Tue, 1 Apr 2008 22:18:44 -0600 Subject: [FLASH-USERS] Tecplot Message-ID: Greetings, Has anyone successfully used Tecplot to visualize FLASH data? Currently when I try to read FLASH-generated HDF5 files into Tecplot it complains that 4D arrays are not supported. I'm only using two spatial dimensions but apparently the output arrays are 4D, at least according to Tecplot. Is there an easy way around this? At the moment I'm using FLASH2.5 and Tecplot 360-2008. It's not a problem with the data itself - it looks fine when I view it in IDL. Thanks for any comments, - Mark Mark Miesch HAO/NCAR Boulder, CO 80307-3000 303-497-1582 miesch at ucar.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080401/8f60916c/attachment.html From gawrysz at camk.edu.pl Wed Apr 2 00:11:17 2008 From: gawrysz at camk.edu.pl (Artur Gawryszczak) Date: Wed, 2 Apr 2008 06:11:17 +0100 Subject: [FLASH-USERS] Tecplot In-Reply-To: References: Message-ID: <200804020711.17727@phoenix.camk.edu.pl> Hi Mark, On ?roda, 2 kwietnia 2008, Mark Miesch wrote: > [...] I'm only using two spatial dimensions but apparently the output > arrays are 4D, at least according to Tecplot. The arrays are 4D because they always contain 3D data (in your case 3rd dimension has only single cell) and additional dimension counts blocks. > Is there an easy way around this? If your grid does not use AMR then you may read hdf5 file and assemble an uniformly spaced 2D array using top-level blocks. See source of sfocu tool how to do simple reading. You'll also need to understand 'gid' array (explained in the manual for FLASH). If you use AMR then things aren't that easy and you must decide how to handle non-uniformity of the grid caused by resolution changes. Alternatively you may try to make a sub-unit in I/O tree that will produce desired 2D output. -- Cheers, Artur From tomek at scs.fsu.edu Wed Apr 2 07:24:25 2008 From: tomek at scs.fsu.edu (Tomasz Plewa) Date: Wed, 02 Apr 2008 08:24:25 -0400 Subject: [FLASH-USERS] Tecplot In-Reply-To: <200804020711.17727@phoenix.camk.edu.pl> References: <200804020711.17727@phoenix.camk.edu.pl> Message-ID: <20080402082425.fdieblwnwwcs08w8@webmail.scs.fsu.edu> Mark, Artur - There is FLASH-Tecplot format converter available in FLASH2 distribution: $FLASH_ROOT/tools/flash2tec I have no experience with using it, but it was extensively used in the Center's work in the past and some of its users might still be around to help. Cheers - 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/ -- Artur Gawryszczak wrote: > Hi Mark, > > On ?roda, 2 kwietnia 2008, Mark Miesch wrote: >> [...] I'm only using two spatial dimensions but apparently the output >> arrays are 4D, at least according to Tecplot. > > The arrays are 4D because they always contain 3D data (in your case 3rd > dimension has only single cell) and additional dimension counts blocks. > >> Is there an easy way around this? > > If your grid does not use AMR then you may read hdf5 file and assemble an > uniformly spaced 2D array using top-level blocks. See source of sfocu tool > how to do simple reading. You'll also need to understand 'gid' array > (explained in the manual for FLASH). If you use AMR then things aren't that > easy and you must decide how to handle non-uniformity of the grid caused by > resolution changes. > > Alternatively you may try to make a sub-unit in I/O tree that will produce > desired 2D output. > > -- > Cheers, > Artur > > -- > 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 andreas at irf.se Wed Apr 2 07:56:09 2008 From: andreas at irf.se (=?windows-1252?Q?Andreas_Ekenb=E4ck?=) Date: Wed, 02 Apr 2008 14:56:09 +0200 Subject: [FLASH-USERS] Suddenly FLASH doesn't work anymore on Linux desktop Message-ID: <47F38269.3050600@irf.se> Hi all, I have been running FLASH2.5 on my desktop computer for a while, but since a couple of days it suddenly doesn't work anymore. Some libraries have been upgraded since the last successful runs of FLASH. Specifically there was an upgrade of bzip2 and libbz2 that I can't undo. I have reinstalled MPICH2, ifort and icc today without improvements. I can run for example the sedov setup, but we have 2 own setups that suddenly do not work anymore. Both setups use particles, otherwise there is nothing fundamentally different. Our setups output the first chk- and plotfiles (0000) and then crashes at the first time step. And note that it's only on this computer that our setups do not work. The longest error messages we have been able to achieve: ---- forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source flash2 0000000000480427 Unknown Unknown Unknown flash2 0000000000429525 Unknown Unknown Unknown flash2 000000000041A0D1 Unknown Unknown Unknown flash2 0000000000405162 Unknown Unknown Unknown libc.so.6 00002AB64040DB44 Unknown Unknown Unknown flash2 00000000004050A9 Unknown Unknown Unknown [cli_0]: aborting job: Fatal error in MPI_Ssend: Other MPI error, error stack: MPI_Ssend(167)............................: MPI_Ssend(buf=0x12d9ba0, count=1, dtype=USER, dest=1, tag=14, MPI_COMM_WORLD) failed MPIDI_CH3i_Progress_wait(215).............: an error occurred while handling an event returned by MPIDU_Sock_Wait() MPIDI_CH3I_Progress_handle_sock_event(420): MPIDU_Socki_handle_read(633)..............: connection failure (set=0,sock=1,errno=104:(strerror() not found)) ---- System information: - Linux hybrid.irf.se 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008 x86_64 GNU/Linux - ifort 10.1.012 So... - anyone had the same problem? - any ideas how to continue problem solving? - is there some indirect dependence on libbz2 (i.e. could that upgrade be guilty?) --- ldd ./flash2 libfmpich.so.1.1 => /opt/mpich/mpich2-1.0.6p1/lib/libfmpich.so.1.1 (0x00002b834be0b000) libmpich.so.1.1 => /opt/mpich/mpich2-1.0.6p1/lib/libmpich.so.1.1 (0x00002b834c021000) libpthread.so.0 => /lib/libpthread.so.0 (0x00002b834c3c3000) librt.so.1 => /lib/librt.so.1 (0x00002b834c5de000) libm.so.6 => /lib/libm.so.6 (0x00002b834c7e8000) libc.so.6 => /lib/libc.so.6 (0x00002b834ca69000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b834cdc4000) libdl.so.2 => /lib/libdl.so.2 (0x00002b834cfd3000) /lib64/ld-linux-x86-64.so.2 (0x00002b834bbed000) --- Thankful for any help /Andreas -- Andreas Ekenb?ck ? andreas at irf.se ? +46 (0)980 79113 ? http://www.irf.se/link/Andreas_Ekenback Swedish Institute of Space Physics ? www.irf.se From latife at astro.rug.nl Fri Apr 4 10:00:22 2008 From: latife at astro.rug.nl (M.A. Latife) Date: Fri, 04 Apr 2008 17:00:22 +0200 Subject: [FLASH-USERS] Using cosmology Module Message-ID: <47F64286.60603@astro.rug.nl> Hi, Dear All, I am runing simulations using cosmology module starting from Redshift 25 but i am getting this warning "WARNING: RedshiftToTimeConversion: dtdz not valid" I am afraid it might be effecting my results. why i receive this warning. what could be possible solution. any suggestion in this regard will be highly appreciated kind regards Latife From pmricker at uiuc.edu Fri Apr 4 11:27:12 2008 From: pmricker at uiuc.edu (Paul Ricker) Date: Fri, 04 Apr 2008 11:27:12 -0500 Subject: [FLASH-USERS] Using cosmology Module In-Reply-To: <47F64286.60603@astro.rug.nl> References: <47F64286.60603@astro.rug.nl> Message-ID: <1207326432.4857.6.camel@denali.localdomain> Latife, This message means that for the cosmology and the number of tabulated points you have chosen, the RedshiftToTimeConversion routine does not have an expression for dt/dz and cannot compute it via finite difference. The message is completely harmless, and you can ignore it (comment it out if you like). RedshiftToTime is only called once by FLASH, and only to compute tinitial if zinitial is specified. The dtdz output of RedshiftToTimeConversion is not used. (It's there in case some other cosmology-dependent routine wants it in the future.) Since the message comes up so often, it should probably be suppressed, or else (better) the condition that causes it should be dealt with. Best, Paul On Fri, 2008-04-04 at 17:00 +0200, M.A. Latife wrote: > Hi, > Dear All, > I am runing simulations using cosmology module starting from Redshift > 25 but i am getting this warning > "WARNING: RedshiftToTimeConversion: dtdz not valid" > I am afraid it might be effecting my results. why i receive this > warning. what could be possible solution. > any suggestion in this regard will be highly appreciated > kind regards > Latife -- --------------------------------------------------------------------- Paul M. Ricker Department of Astronomy Assistant Professor National Center for Supercomputing Applications pmricker at uiuc.edu University of Illinois at Urbana-Champaign http://www.astro.uiuc.edu/~pmricker Urbana IL 61801-3074 --------------------------------------------------------------------- From seyit at astro.rug.nl Fri Apr 4 12:03:28 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Fri, 04 Apr 2008 19:03:28 +0200 Subject: [FLASH-USERS] Running simulations on a cluster In-Reply-To: <47F64286.60603@astro.rug.nl> References: <47F64286.60603@astro.rug.nl> Message-ID: <47F65F60.8080003@astro.rug.nl> Dear Flash-users Community, I have a problem which I heard before and am experience it now myself. I hope it was solved and that people can help me with it. I am resolution limited while running simulations on 1 cpu, however whenever I use the computer cluster that is available to me with 20 cpu's, I notice that it's not faster at all. In fact, it's even a little bit slower. My machine is not that great compared to the machines of the cluster. I suspect that dividing the tasks is not done very well. Perhaps it is some kind of optimalization problems, because I use an intel cpu and the cluster has amd (Opteron). Or it could be that I/O is very slow on the cluster, but this should not be the limiting case. I am afraid though that my setting up of the simulation might be wrong, because every node (machine) has to connect to the master cpu at every timestep (dt). Any help is much appreciated. Kind regards, Seyit Btw: I am using mpich2 and create a ring of cpu's with mpdboot --totalnum=.. --file=.. and start the simulation with mpiexec -n X. With mpdtrace I do see that multiple machines are within the ring and so directly assume that multiple machines are used. I don't know any other way to see that the task is divided. From latife at astro.rug.nl Fri Apr 4 12:44:52 2008 From: latife at astro.rug.nl (M.A. Latife) Date: Fri, 04 Apr 2008 19:44:52 +0200 Subject: [FLASH-USERS] Error while using cosmology Module Message-ID: <47F66914.6050106@astro.rug.nl> Hi, Dear all, I am simulating gravitational collapse( Grvity module + hydro module + cooling ) and i have included cooling as well. My simulation were running fine but when i have plugged in cosmological Module. module . it starts giving an error. that desired time step is lower than minimum . when i reduce the time step it again gives this message look at the output below. why it is happening like this? can you suggest something. kind regards Latife *** Wrote output to testsph_hdf5_plt_cnt_0000 *** n t dt | dt_hydro dt_cosmo 1 4.3639E+15 1.8928E+10 | 1.893E+10 6.546E+14 2 4.3640E+15 2.0004E+10 | 2.000E+10 6.546E+14 3 4.3640E+15 2.0354E+10 | 2.035E+10 6.546E+14 4 4.3640E+15 2.0405E+10 | 2.040E+10 6.546E+14 5 4.3641E+15 2.0438E+10 | 2.044E+10 6.546E+14 6 4.3641E+15 2.0436E+10 | 2.044E+10 6.546E+14 7 4.3642E+15 2.0428E+10 | 2.043E+10 6.546E+14 8 4.3642E+15 2.0416E+10 | 2.042E+10 6.546E+14 9 4.3642E+15 2.0404E+10 | 2.040E+10 6.546E+14 10 4.3643E+15 2.0392E+10 | 2.039E+10 6.546E+14 11 4.3643E+15 2.0380E+10 | 2.038E+10 6.546E+14 12 4.3644E+15 2.0369E+10 | 2.037E+10 6.546E+14 13 4.3644E+15 2.0359E+10 | 2.036E+10 6.546E+14 14 4.3644E+15 2.0351E+10 | 2.035E+10 6.546E+14 15 4.3645E+15 2.0346E+10 | 2.035E+10 6.546E+14 16 4.3645E+15 2.0343E+10 | 2.034E+10 6.547E+14 17 4.3646E+15 2.0342E+10 | 2.034E+10 6.547E+14 18 4.3646E+15 2.0343E+10 | 2.034E+10 6.547E+14 19 4.3646E+15 2.1490E+10 | 2.149E+10 6.547E+14 20 4.3647E+15 2.2372E+10 | 2.237E+10 6.547E+14 21 4.3647E+15 3.1002E+10 | 3.100E+10 6.547E+14 WARNING: desired timestep < dtmin, using dtmin 22 4.3648E+15 1.0000E+08 | 1.160E+06 6.547E+14 WARNING: desired timestep < dtmin, using dtmin 23 4.3648E+15 1.0000E+08 | 1.838E-04 6.547E+14 WARNING: desired timestep < dtmin, using dtmin 24 4.3648E+15 1.0000E+08 | 3.838-104 6.547E+14 WARNING: desired timestep < dtmin, using dtmin 25 4.3648E+15 1.0000E+08 | 0.000E+00 6.547E+14 min_blocks 450 max_blocks 450 tot_blocks 450 26 4.3648E+15 2.0000E+08 | 6.547E+14 27 4.3648E+15 4.0000E+08 | 6.547E+14 28 4.3648E+15 8.0000E+08 | 6.547E+14 29 4.3648E+15 1.6000E+09 | 6.547E+14 30 4.3648E+15 3.2000E+09 | 6.547E+14 31 4.3648E+15 6.4000E+09 | 6.547E+14 From geoff at mso.anu.edu.au Mon Apr 7 02:45:26 2008 From: geoff at mso.anu.edu.au (Geoff Bicknell) Date: Mon, 7 Apr 2008 17:45:26 +1000 Subject: [FLASH-USERS] Sedov and Sod test problems in Flash 3.0 Message-ID: First of all thanks to the people (esp. Klaus Weide) who helped us to get FLASH 3 compiling under Solaris. We are now having problems getting FLASH running in AMR mode. Running in single processor mode the dbx output is: [1] t_delete(0x4a63974, 0x4a63978, 0xffffffffffffffff, 0x0, 0x0, 0xfffffd7ffb3e8b80), at 0xfffffd7ffb3601e3 [2] realfree(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffb35fe03 [3] cleanfree(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffb3604cf [4] _malloc_unlocked(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffb35f769 [5] malloc(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffb35f6cd =>[6] compress_list(neigh_morts = ASSUMED-SHAPE ARRAY, istack = 12, no_of_remote_neighs = 0, mype = 0, nprocs = 1, l_on_pe = true), line 1630 in "mpi_morton_bnd.F90" [7] mpi_morton_bnd_fluxcon(mype = 0, nprocs = 1, tag_offset = 100), line 303 in "mpi_morton_bnd_fluxcon.F90" [8] amr_morton_process(), line 807 in "mpi_amr_refine_derefine.F90" [9] amr_refine_derefine(), line 602 in "mpi_amr_refine_derefine.F90" [10] gr_expanddomain(mype = 0, numprocs = 1, particlesinitialized = false), line 188 in "gr_expandDomain.F90" [11] grid_initdomain(mype = 0, numprocs = 1, restart = false, particlesinitialized = false), line 94 in "Grid_initDomain.F90" [12] driver_initflash(), line 146 in "Driver_initFlash.F90" [13] MAIN(), line 40 in "Flash.F90" Flash is trying to do a malloc with parameters all set to 0. We are using the standard flash.par that comes with the 3.0 distribution. We also have similar problems with the Sod test. We get similar errors running in multiprocessor mode (e.g. np=2 or 4). When we run FLASH in Uniform Grid mode, it runs successfully. The computer is an 8 processor SUN with AMD processors running Solaris 5.10 Thanks, Geoff Bicknell -- ================================================================================ Professor Geoffrey Bicknell, Associate Director (Academic) Research School of Astronomy & Astrophysics, Australian National University, Mt Stromlo Observatory, Cotter Rd., Weston ACT 2611, AUSTRALIA T:+61 (0)2 6125 0245 M: +61 (0)402 302 802 F: +61 (0)2 6125 0260 W: http://www.mso.anu.edu.au/~geoff ================================================================================ (ANU CRICOS #00120C) From cdaley at flash.uchicago.edu Mon Apr 7 10:35:54 2008 From: cdaley at flash.uchicago.edu (Chris Daley) Date: Mon, 07 Apr 2008 10:35:54 -0500 Subject: [FLASH-USERS] Suddenly FLASH doesn't work anymore on Linux desktop In-Reply-To: <47F38269.3050600@irf.se> References: <47F38269.3050600@irf.se> Message-ID: <47FA3F5A.9000305@flash.uchicago.edu> Hi Andreas, It seems to me that there is a run-time error in your custom setup, such as, an array being overrun. I am guessing this because invalid memory accesses do not always cause an application to crash. Could you please build your setup in "debug" mode, i.e: ./setup -debug [other options] This will create a Makefile with compiler flags that are useful for debugging. In the case of the ifort compiler, the debug setup will specify that the "-check bounds" option is included during compilation, which will verify whether all array accesses are within declared bounds. This should give a more detailed error message which will likely include the exact line number where the violation occurred. It should be possible to resolve the problem with this extra information. Kind Regards, Chris Andreas Ekenb?ck wrote: > Hi all, > > I have been running FLASH2.5 on my desktop computer for a while, but > since a couple of days it suddenly doesn't work anymore. > > Some libraries have been upgraded since the last successful runs of > FLASH. Specifically there was an upgrade of bzip2 and libbz2 that I > can't undo. I have reinstalled MPICH2, ifort and icc today without > improvements. > > I can run for example the sedov setup, but we have 2 own setups that > suddenly do not work anymore. Both setups use particles, otherwise > there is nothing fundamentally different. Our setups output the first > chk- and plotfiles (0000) and then crashes at the first time step. And > note that it's only on this computer that our setups do not work. > The longest error messages we have been able to achieve: > ---- > > forrtl: severe (174): SIGSEGV, segmentation fault occurred > Image PC Routine Line > Source flash2 0000000000480427 > Unknown Unknown Unknown > flash2 0000000000429525 Unknown Unknown > Unknown > flash2 000000000041A0D1 Unknown Unknown > Unknown > flash2 0000000000405162 Unknown Unknown > Unknown > libc.so.6 00002AB64040DB44 Unknown Unknown > Unknown > flash2 00000000004050A9 Unknown Unknown > Unknown > [cli_0]: aborting job: > Fatal error in MPI_Ssend: Other MPI error, error stack: > MPI_Ssend(167)............................: MPI_Ssend(buf=0x12d9ba0, > count=1, dtype=USER, dest=1, tag=14, MPI_COMM_WORLD) failed > MPIDI_CH3i_Progress_wait(215).............: an error occurred while > handling an event returned by MPIDU_Sock_Wait() > MPIDI_CH3I_Progress_handle_sock_event(420): > MPIDU_Socki_handle_read(633)..............: connection failure > (set=0,sock=1,errno=104:(strerror() not found)) > > ---- > > System information: > - Linux hybrid.irf.se 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC > 2008 x86_64 GNU/Linux > - ifort 10.1.012 > > So... > - anyone had the same problem? > - any ideas how to continue problem solving? > - is there some indirect dependence on libbz2 (i.e. could that upgrade > be guilty?) > > --- > ldd ./flash2 > libfmpich.so.1.1 => /opt/mpich/mpich2-1.0.6p1/lib/libfmpich.so.1.1 > (0x00002b834be0b000) > libmpich.so.1.1 => /opt/mpich/mpich2-1.0.6p1/lib/libmpich.so.1.1 > (0x00002b834c021000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00002b834c3c3000) > librt.so.1 => /lib/librt.so.1 (0x00002b834c5de000) > libm.so.6 => /lib/libm.so.6 (0x00002b834c7e8000) > libc.so.6 => /lib/libc.so.6 (0x00002b834ca69000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b834cdc4000) > libdl.so.2 => /lib/libdl.so.2 (0x00002b834cfd3000) > /lib64/ld-linux-x86-64.so.2 (0x00002b834bbed000) > --- > > Thankful for any help > /Andreas > > From klaus at flash.uchicago.edu Mon Apr 7 11:06:00 2008 From: klaus at flash.uchicago.edu (Klaus Weide) Date: Mon, 7 Apr 2008 11:06:00 -0500 (CDT) Subject: [FLASH-USERS] Sedov and Sod test problems in Flash 3.0 In-Reply-To: References: Message-ID: On Mon, 7 Apr 2008, Geoff Bicknell wrote: > We are now having problems getting FLASH running in AMR mode. Running in > single processor mode the dbx output is: > [ snip ] > [5] malloc(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffb35f6cd > =>[6] compress_list(neigh_morts = ASSUMED-SHAPE ARRAY, istack = 12, > no_of_remote_neighs = 0, mype = 0, nprocs = 1, l_on_pe = true), line 1630 in "mpi_morton_bnd.F90" > [7] mpi_morton_bnd_fluxcon(mype = 0, nprocs = 1, tag_offset = 100), line 303 in "mpi_morton_bnd_fluxcon.F90" > [8] amr_morton_process(), line 807 in "mpi_amr_refine_derefine.F90" > [9] amr_refine_derefine(), line 602 in "mpi_amr_refine_derefine.F90" [ snip ] > Flash is trying to do a malloc with parameters all set to 0. We are using the > standard flash.par that comes with the 3.0 distribution. We also have similar > problems with the Sod test. Geoff, First of all, I don't think the code is doing something illegal there; maybe your compiler (or runtime library) is overly picky -- are there some flags you could use to make it less so? -- or perhaps it cannot deal with an unusual situation. Would you please verify that in your code the statement that begins on line 1630 in "mpi_morton_bnd.F90" looks like this: call amr_q_sort(neigh_morts(6,2,istart:iend),iend-istart+1, & ia=indx(istart:iend)) If yes, please try the following: replace the call amr_q_sort(... with if (iend>istart) call amr_q_sort(... BOTH on line 1630 and a few lines down. This suggestion is based on the assumption that the compiler is generating a temporary array for the neigh_morts(6,2,istart:iend) argument, and that this somehow fails when istart>=iend. I have no way of testing locally if this is really the cause of your failure. Please let me know if this results in any improvement - perhaps there are are other places where similar changes are necessary. Klaus Weide From seyit at astro.rug.nl Mon Apr 21 08:10:02 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Mon, 21 Apr 2008 15:10:02 +0200 Subject: [FLASH-USERS] Changing Gamma (eos) Message-ID: <480C922A.2090006@astro.rug.nl> Hi all, I have a simple question. I want to put a changing gamma in my simulation. e.g. a gamma which changes and depends on dt. Where to change this formula of gamma? I can't locate it in the database. Thanks, Seyit From dubey at flash.uchicago.edu Mon Apr 21 11:00:01 2008 From: dubey at flash.uchicago.edu (Anshu Dubey) Date: Mon, 21 Apr 2008 11:00:01 -0500 (CDT) Subject: [FLASH-USERS] Changing Gamma (eos) In-Reply-To: <480C922A.2090006@astro.rug.nl> References: <480C922A.2090006@astro.rug.nl> Message-ID: <52124.128.135.199.47.1208793601.squirrel@flash.uchicago.edu> Hi Seyit, This feature is not a part of FLASH default behavior. If you are using FLASH3 then you have two options. The value of gamma in Eos is carried in a variable called eos_gamma, which is defined in the data module for the Eos unit, in file "source/physics/Eos/EosMain/Eos_data.F90". Normally this variable is initialized in Eos_init, and then used in "Eos.F90". Your first and simplest option is to add a line at the beginning of "Eos.F90" to update the eos_gamma value at each time step. You can fetch the value of dt by calling the function "Driver_getDt". If you need time dependent gamma for only one setup, then the better option is to place a copy of Eos.F90 in the simulation directory and modify that file as described above. That way you won't have to worry about the source tree when you get later versions of FLASH. Anshu > Hi all, > > I have a simple question. I want to put a changing gamma in my > simulation. e.g. a gamma which changes and depends on dt. Where to > change this formula of gamma? > > I can't locate it in the database. > > Thanks, > Seyit > From seyit at astro.rug.nl Mon Apr 21 12:20:15 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Mon, 21 Apr 2008 19:20:15 +0200 Subject: [FLASH-USERS] Changing Gamma (eos) In-Reply-To: <52124.128.135.199.47.1208793601.squirrel@flash.uchicago.edu> References: <480C922A.2090006@astro.rug.nl> <52124.128.135.199.47.1208793601.squirrel@flash.uchicago.edu> Message-ID: <480CCCCF.8040905@astro.rug.nl> Hi Anshu, I am using FLASH2.5 and it might be a little different to version 3.0. Though I have tried to change things in eos.F90, but the unfortunate thing is that (pretty sure) eos.F90 is not called at every timestep 'dt'. It is (might be) only used when initializing the blocks. This is of no use to me. I want to update gamma like you say at every timestep (gamma will be dependant on temperature and density basically). In Flash2.5, the eos.F90 is in "source/materials/eos/gamma/". Btw. I am using a module eos1d inside my "init_block.F90" file. Of course, changing the formula of gamma there isn't helping. Thanks, Seyit > Hi Seyit, > > This feature is not a part of FLASH default behavior. If you are using > FLASH3 then you have two options. The value of gamma in Eos is carried > in a variable called eos_gamma, which is defined in the data module for > the Eos unit, in file "source/physics/Eos/EosMain/Eos_data.F90". Normally > this variable is initialized in Eos_init, and then used in "Eos.F90". > Your first and simplest option is to add a line > at the beginning of "Eos.F90" to update the eos_gamma value at each time > step. You can fetch the value of dt by calling the function > "Driver_getDt". If you need time dependent gamma for only one > setup, then the better option is to place a copy of Eos.F90 in the > simulation directory and modify that file as described above. That way > you won't have to worry about the source tree when you get later > versions of FLASH. > > Anshu > > >> Hi all, >> >> I have a simple question. I want to put a changing gamma in my >> simulation. e.g. a gamma which changes and depends on dt. Where to >> change this formula of gamma? >> >> I can't locate it in the database. >> >> Thanks, >> Seyit >> >> From dubey at flash.uchicago.edu Mon Apr 21 13:21:51 2008 From: dubey at flash.uchicago.edu (Anshu Dubey) Date: Mon, 21 Apr 2008 13:21:51 -0500 (CDT) Subject: [FLASH-USERS] Changing Gamma (eos) In-Reply-To: <480CCCCF.8040905@astro.rug.nl> References: <480C922A.2090006@astro.rug.nl> <52124.128.135.199.47.1208793601.squirrel@flash.uchicago.edu> <480CCCCF.8040905@astro.rug.nl> Message-ID: <52470.128.135.199.47.1208802111.squirrel@flash.uchicago.edu> Hi Seyit, In FLASH 2.5 you need to make that change in eos1d.F90 also. Anshu Anshu > Hi Anshu, > > I am using FLASH2.5 and it might be a little different to version 3.0. > Though I have tried to change things in eos.F90, but the unfortunate > thing is that (pretty sure) eos.F90 is not called at every timestep > 'dt'. It is (might be) only used when initializing the blocks. This is > of no use to me. I want to update gamma like you say at every timestep > (gamma will be dependant on temperature and density basically). > > In Flash2.5, the eos.F90 is in "source/materials/eos/gamma/". > > Btw. I am using a module eos1d inside my "init_block.F90" file. Of > course, changing the formula of gamma there isn't helping. > > Thanks, > Seyit > > >> Hi Seyit, >> >> This feature is not a part of FLASH default behavior. If you are using >> FLASH3 then you have two options. The value of gamma in Eos is carried >> in a variable called eos_gamma, which is defined in the data module for >> the Eos unit, in file "source/physics/Eos/EosMain/Eos_data.F90". >> Normally >> this variable is initialized in Eos_init, and then used in "Eos.F90". >> Your first and simplest option is to add a line >> at the beginning of "Eos.F90" to update the eos_gamma value at each time >> step. You can fetch the value of dt by calling the function >> "Driver_getDt". If you need time dependent gamma for only one >> setup, then the better option is to place a copy of Eos.F90 in the >> simulation directory and modify that file as described above. That way >> you won't have to worry about the source tree when you get later >> versions of FLASH. >> >> Anshu >> >> >>> Hi all, >>> >>> I have a simple question. I want to put a changing gamma in my >>> simulation. e.g. a gamma which changes and depends on dt. Where to >>> change this formula of gamma? >>> >>> I can't locate it in the database. >>> >>> Thanks, >>> Seyit >>> >>> > From seyit at astro.rug.nl Tue Apr 22 03:27:58 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Tue, 22 Apr 2008 10:27:58 +0200 Subject: [FLASH-USERS] Changing Gamma (eos) In-Reply-To: <52470.128.135.199.47.1208802111.squirrel@flash.uchicago.edu> References: <480C922A.2090006@astro.rug.nl> <52124.128.135.199.47.1208793601.squirrel@flash.uchicago.edu> <480CCCCF.8040905@astro.rug.nl> <52470.128.135.199.47.1208802111.squirrel@flash.uchicago.edu> Message-ID: <480DA18E.8040601@astro.rug.nl> Hi Anshu, Like I said, I made that change in eos1d.F90 already. However, that file is only used when initialising FLASH. It is not used at every timestep. This is the whole issue. If I change the formula there, it will only calculate once in the beginning, then it will use that value throughout the whole simulation. Seyit > Hi Seyit, > > In FLASH 2.5 you need to make that change in eos1d.F90 also. > > Anshu > > Anshu > > >> Hi Anshu, >> >> I am using FLASH2.5 and it might be a little different to version 3.0. >> Though I have tried to change things in eos.F90, but the unfortunate >> thing is that (pretty sure) eos.F90 is not called at every timestep >> 'dt'. It is (might be) only used when initializing the blocks. This is >> of no use to me. I want to update gamma like you say at every timestep >> (gamma will be dependant on temperature and density basically). >> >> In Flash2.5, the eos.F90 is in "source/materials/eos/gamma/". >> >> Btw. I am using a module eos1d inside my "init_block.F90" file. Of >> course, changing the formula of gamma there isn't helping. >> >> Thanks, >> Seyit >> >> >> >>> Hi Seyit, >>> >>> This feature is not a part of FLASH default behavior. If you are using >>> FLASH3 then you have two options. The value of gamma in Eos is carried >>> in a variable called eos_gamma, which is defined in the data module for >>> the Eos unit, in file "source/physics/Eos/EosMain/Eos_data.F90". >>> Normally >>> this variable is initialized in Eos_init, and then used in "Eos.F90". >>> Your first and simplest option is to add a line >>> at the beginning of "Eos.F90" to update the eos_gamma value at each time >>> step. You can fetch the value of dt by calling the function >>> "Driver_getDt". If you need time dependent gamma for only one >>> setup, then the better option is to place a copy of Eos.F90 in the >>> simulation directory and modify that file as described above. That way >>> you won't have to worry about the source tree when you get later >>> versions of FLASH. >>> >>> Anshu >>> >>> >>> >>>> Hi all, >>>> >>>> I have a simple question. I want to put a changing gamma in my >>>> simulation. e.g. a gamma which changes and depends on dt. Where to >>>> change this formula of gamma? >>>> >>>> I can't locate it in the database. >>>> >>>> Thanks, >>>> Seyit >>>> >>>> >>>> From dubey at flash.uchicago.edu Tue Apr 22 08:11:20 2008 From: dubey at flash.uchicago.edu (Anshu Dubey) Date: Tue, 22 Apr 2008 08:11:20 -0500 (CDT) Subject: [FLASH-USERS] Changing Gamma (eos) In-Reply-To: <480DA18E.8040601@astro.rug.nl> References: <480C922A.2090006@astro.rug.nl> <52124.128.135.199.47.1208793601.squirrel@flash.uchicago.edu> <480CCCCF.8040905@astro.rug.nl> <52470.128.135.199.47.1208802111.squirrel@flash.uchicago.edu> <480DA18E.8040601@astro.rug.nl> Message-ID: <62321.75.3.149.205.1208869880.squirrel@flash.uchicago.edu> Hi Seyit, First, if at all possible for you, please switch to FLASH3. There is one person in the center who is using FLASH2 for any work. And there are at best 4-5 people who used FLASH2 more than two years ago, so even though they have used it, they are not very familiar with it any more. In the code group at the center I am the only one left who has had anything to do with FLASH2 at all. Your statement that eos1d is called only at initialization is not accurate. If you look at hydro_sweep, there is a call to eos3d after update solution at every sweep. Eos3d in turn calls eos1d. So gamma should be getting updated every timestep. However, if you need this update at the beginning of hydro calculation rather than at the end, you should copy hydro_sweep into you directory, and move the eos3d call for the entire block (including the guardcells) after the guardcell fill call. Anshu > Hi Anshu, > > Like I said, I made that change in eos1d.F90 already. However, that file > is only used when initialising FLASH. It is not used at every timestep. > This is the whole issue. If I change the formula there, it will only > calculate once in the beginning, then it will use that value throughout > the whole simulation. > > Seyit > > > >> Hi Seyit, >> >> In FLASH 2.5 you need to make that change in eos1d.F90 also. >> >> Anshu >> >> Anshu >> >> >>> Hi Anshu, >>> >>> I am using FLASH2.5 and it might be a little different to version 3.0. >>> Though I have tried to change things in eos.F90, but the unfortunate >>> thing is that (pretty sure) eos.F90 is not called at every timestep >>> 'dt'. It is (might be) only used when initializing the blocks. This is >>> of no use to me. I want to update gamma like you say at every timestep >>> (gamma will be dependant on temperature and density basically). >>> >>> In Flash2.5, the eos.F90 is in "source/materials/eos/gamma/". >>> >>> Btw. I am using a module eos1d inside my "init_block.F90" file. Of >>> course, changing the formula of gamma there isn't helping. >>> >>> Thanks, >>> Seyit >>> >>> >>> >>>> Hi Seyit, >>>> >>>> This feature is not a part of FLASH default behavior. If you are using >>>> FLASH3 then you have two options. The value of gamma in Eos is carried >>>> in a variable called eos_gamma, which is defined in the data module >>>> for >>>> the Eos unit, in file "source/physics/Eos/EosMain/Eos_data.F90". >>>> Normally >>>> this variable is initialized in Eos_init, and then used in "Eos.F90". >>>> Your first and simplest option is to add a line >>>> at the beginning of "Eos.F90" to update the eos_gamma value at each >>>> time >>>> step. You can fetch the value of dt by calling the function >>>> "Driver_getDt". If you need time dependent gamma for only one >>>> setup, then the better option is to place a copy of Eos.F90 in the >>>> simulation directory and modify that file as described above. That way >>>> you won't have to worry about the source tree when you get later >>>> versions of FLASH. >>>> >>>> Anshu >>>> >>>> >>>> >>>>> Hi all, >>>>> >>>>> I have a simple question. I want to put a changing gamma in my >>>>> simulation. e.g. a gamma which changes and depends on dt. Where to >>>>> change this formula of gamma? >>>>> >>>>> I can't locate it in the database. >>>>> >>>>> Thanks, >>>>> Seyit >>>>> >>>>> >>>>> > From seyit at astro.rug.nl Wed Apr 23 11:39:02 2008 From: seyit at astro.rug.nl (Seyit Hocuk) Date: Wed, 23 Apr 2008 18:39:02 +0200 Subject: [FLASH-USERS] Refinement and Derefinement Criteria Message-ID: <480F6626.9010403@astro.rug.nl> Hi all, First of all thanks Anshu. I have somthing to work on now. I also consider to switch to FLASH3.0. However, I have another question for anybody who can reply. Sorry that I ask many questions, but this should be a simple one. Flash, as I believe, refines automatically when you don't put lrefine_max equal to lrefine_min. With witch criteria can I play with the refinement and how can I say when to derefine. Basically I don't completely understand how refinement works and the user guide is not completely transparant about this. I assumed that delta_ref, delta_deref and the reference_density were exactly these parameters. I initially thought that when the density "rho" (or whatever parameter is set for refinement) at each block exceeds the reference density by amount of delta_ref (multiplied or added?) then it refines and when it is lower by an amount of delta_deref it derefines. However, changing these parameters has proven to have little effect for me. Can anybody explain me how this works and what the formula's are if any? TY, Seyit From rfisher at flash.uchicago.edu Wed Apr 23 12:46:47 2008 From: rfisher at flash.uchicago.edu (Robert Fisher) Date: Wed, 23 Apr 2008 12:46:47 -0500 (CDT) Subject: [FLASH-USERS] Refinement and Derefinement Criteria In-Reply-To: <480F6626.9010403@astro.rug.nl> References: <480F6626.9010403@astro.rug.nl> Message-ID: Hi Seyit : What criterion one chooses to refine an adaptive mesh depends crucially upon what physics one is simulating, and what scientific questions one is seeking to address. There is no single silver bullet here -- while it is clearly advisable to fully resolve all characteristic length scales throughout all space and time in the problem under consideration, you will need to critically assess the tradeoff of what additional information is learned with the added cost of the simulation. Best wishes, Bob On Wed, 23 Apr 2008, Seyit Hocuk wrote: > Hi all, > > First of all thanks Anshu. I have somthing to work on now. I also consider to > switch to FLASH3.0. However, I have another question for anybody who can > reply. Sorry that I ask many questions, but this should be a simple one. > > Flash, as I believe, refines automatically when you don't put lrefine_max > equal to lrefine_min. With witch criteria can I play with the refinement and > how can I say when to derefine. Basically I don't completely understand how > refinement works and the user guide is not completely transparant about this. > I assumed that delta_ref, delta_deref and the reference_density were exactly > these parameters. I initially thought that when the density "rho" (or > whatever parameter is set for refinement) at each block exceeds the reference > density by amount of delta_ref (multiplied or added?) then it refines and > when it is lower by an amount of delta_deref it derefines. However, changing > these parameters has proven to have little effect for me. > > Can anybody explain me how this works and what the formula's are if any? > > TY, > Seyit > > From klaus at flash.uchicago.edu Wed Apr 23 15:08:20 2008 From: klaus at flash.uchicago.edu (Klaus Weide) Date: Wed, 23 Apr 2008 15:08:20 -0500 (CDT) Subject: [FLASH-USERS] Refinement and Derefinement Criteria In-Reply-To: References: <480F6626.9010403@astro.rug.nl> Message-ID: On Wed, 23 Apr 2008, Robert Fisher wrote: > Hi Seyit : > > What criterion one chooses to refine an adaptive mesh depends crucially > upon what physics one is simulating, and what scientific questions one is > seeking to address. [...] > > On Wed, 23 Apr 2008, Seyit Hocuk wrote: >> Flash, as I believe, refines automatically when you don't put lrefine_max >> equal to lrefine_min. With witch criteria can I play with the refinement >> and how can I say when to derefine. Basically I don't completely understand >> how refinement works and the user guide is not completely transparant about >> this. I assumed that delta_ref, delta_deref and the reference_density were >> exactly these parameters. I initially thought that when the density "rho" >> (or whatever parameter is set for refinement) at each block exceeds the >> reference density by amount of delta_ref (multiplied or added?) then it >> refines and when it is lower by an amount of delta_deref it derefines. >> However, changing these parameters has proven to have little effect for me. >> >> Can anybody explain me how this works and what the formula's are if any? In addition to Bob Fisher's remarks: FLASH does have a default implementation of refinement/derefinement criteria. This is described in the User's Guide; for FLASH 2.5, in the Mesh chapter under "8.5 Adaptive mesh" (in particular, "8.5.2 Algorithm"). Klaus From latife at astro.rug.nl Tue Apr 29 12:57:01 2008 From: latife at astro.rug.nl (M.A. Latife) Date: Tue, 29 Apr 2008 19:57:01 +0200 Subject: [FLASH-USERS] v cycle not converging Message-ID: <4817616D.40508@astro.rug.nl> Hi, Dear All. First of all sorry for disturbing you again. i am not good in using flash . i am asking many questions hope you will not mind. i am simulating structure formation using FLASH 2.5 starting from redshift 25(Hydro+gravity+cosmology). when i put uniform density over whole domain. i get warning v-cycle not converging and results become worse. i am using periodic boundary conditions both for hydro+ gravity. when i put over density at center (like Gaussian or Mexican hat) minimum density becomes small than it should be at particular redshift( like it becomes 1.0E-30 at redshift 15) although density should remain constant. My 2nd question is when is when using cosmology should i use comoving coordinates when initializing conditions in initial block. if yes then how?. i am taking block centres and dividing them by scale factor in Initial block . any suggestions in this regard will be highly appreciated. Kind regards Latif From geoff at mso.anu.edu.au Wed Apr 30 17:24:43 2008 From: geoff at mso.anu.edu.au (Geoff Bicknell) Date: Thu, 1 May 2008 08:24:43 +1000 Subject: [FLASH-USERS] Bug in Flash3.0 Message-ID: We have been having problems with FLASH3.0 hanging on our SGI Altix computer here at ANU. David Singleton, who is a consultant in the ANU Supercomputer Facility, had a look at this problem for us and identified it as arising from an additional character being written by strcpy. David's comments and proposed fix are below. Geoff Bicknell -------------------------------------------------------------------------------- I think there is a bug in 3.0 that cause segfaults on our Altix system. On our system, setup_buildstats.c has the line: strcpy(build_machine, "Linux ac 2.6.16.53-0.16.PTF.285195.0-default #1 SMP Tue Oct 2 16:57:49 UTC 2007 "); That string contains 80 characters (which is what make_bstats sets up) and build_machine is 80 characters long. But strcpy will also write a trailing '\0', an 81st character, which wipes out whatever comes after build_machine in memory. The patch is below. I haven't checked if there are any other problematic C string library calls. David # diff -w -u object/make_bstats object/make_bstats.NEW --- object/make_bstats 2008-04-28 18:05:38.417096200 +1000 +++ object/make_bstats.NEW 2008-04-30 22:23:46.411828237 +1000 @@ -4,8 +4,8 @@ rm -f setup_buildstats.F90 -max_str_len=80 -long_len=400 +max_str_len=79 +long_len=399 BUILD_DATE=`date | cut -c 1-$max_str_len` BUILD_DIR=`pwd | cut -c 1-$max_str_len` -- ================================================================================ Professor Geoffrey Bicknell, Associate Director (Academic) Research School of Astronomy & Astrophysics, Australian National University, Mt Stromlo Observatory, Cotter Rd., Weston ACT 2611, AUSTRALIA T:+61 (0)2 6125 0245 M: +61 (0)402 302 802 F: +61 (0)2 6125 0260 W: http://www.mso.anu.edu.au/~geoff ================================================================================ (ANU CRICOS #00120C)