[FLASH-USERS] Big Problem??
seyit
seyit at astro.rug.nl
Sat Aug 16 10:02:03 EDT 2008
Hi Chris,
The thing is, I spent many hours already trying to switch to FLASH3.0.
Besides the name changes, the stucture of FLASH has changed in version 3.
Together with my colleague we spent a lot of time but we can't get past
certain things. We want to implement cooling function and for that we need
to implement multispecies were we get problems. We also get stuck when we
want to start with density and temperature instead of density and pressure
thus we need to change the EOS. We must understand the code better in order
to implement these things amongst others. This is the reason that we, for
the moment, still stick with FLASH2.5. Don't think we do not want to switch
to FLASH3.0, we most certainly do.
One other problem we detected with FLASH2.5 jeans setup is that the jeans
setup has its own refinement criteria using delta_ref and delta_deref
together with the reference density. Except that "ctore" or better yet the
refinement_... is not mentioned in the config file of the setup causing an
undefined parameter getting a crazy value depending on compiler. This we
found by accident when we were checking where the differences are coming
from between the two machines (32-bit machine with ifort 8.0 -vs.- 64-bit
machine with ifort 10.1).
Greetz,
Seyit
On Fri, 15 Aug 2008 15:02:39 -0500, Chris Daley <cdaley at flash.uchicago.edu>
wrote:
> Hi Seyit,
>
> The compiler flag is doing its job - we get a run-time error when an
> uninitialised variable is used.
>
> 1. I can confirm that the abort from perfmon.F90 is an error. Notice
> that the subroutine argument is "check_ptnum", but the condition in the
> "if" statement evaluates a variable named "checkpt_num". This emphasises
> the
> importance of "implicit none".
>
> 2. The abort from poisson_mg_relax.F90 stems from a situation which will
> not normally cause problems in a simulation. This is because the "error"
> variable is
> part of the following logical expression.
>
> done = (iter == nsmooth) .or. ((iter > iterating_to_convergence_limit)
> .and. (error > 0.))
>
> i.e. (iter > iterating_to_convergence_limit) .and. (error > 0.). So we
> need both conditions to be .true. to obtain a .true. in the cumulative
> expression.
> In the poisson_mg_relax.F90 source, "error" is only ever
> initialised when "iter" > "iterating_to_convergence_limit", so the
> times when "error" is not initialised will generally not be an issue.
>
> In pursuit of robust code you should correct the code as follows:
>
> 1. Rename "checkpt_num" variable to "check_ptnum"
> 2. Initialise "error" to 0.0 after the variable declaration.
>
>
> If you re-compile and run you will hopefully get a similar kind
> of abort during execution of your simulation specific code. The error
can
> then
> be resolved using similar steps as above. You must keep the -g flag as
it
> gives us line-level information in the stack traces.
>
> Finally, I would recommend that you use FLASH3 if it
> supports the physics that you need. It is much easier for
> us to answer your FLASH3 questions rather than FLASH2 questions,
> and we would rather spend our time making FLASH3 a better
> application.
>
> Chris
>
>
>
>
>
> Seyit Hocuk wrote:
>> Hi Chris, Nathan, Carlo,
>>
>> It has been a while now, but finally I had time to check some stuff.
>> Like Chris said I tried compiling with -CU (check uninit) and also
>> with -ftrapuv. The error with -CU is shown here below. However, the
>> same error is showing when I use normal jeans setup and a different
>> error is generated with Sedov test problem. I think there are many
>> undeclared variables or subroutines anyway. When I use -ftrapuv, I get
>> segmentation faults. These debug options are not much use unfortunately.
>>
>> By the way, what is the use of -g when debugging. It seems like it is
>> doing nothing.
>>
>>
>>
>> * JEANS SETUP
>>
>> perturbation is unstable with growth time 8776137041619.21
>> forrtl: severe (193): Run-Time Check Failure. The variable
>> 'poisson_mg_relax_$ERROR' is being used without being defined
>> Image PC Routine Line
>> Source flash2 00000000005B70FE
>> Unknown Unknown Unknown
>> flash2 00000000005B62FE Unknown Unknown
>> Unknown
>> flash2 000000000056EB56 Unknown Unknown
>> Unknown
>> flash2 0000000000536D51 Unknown Unknown
>> Unknown
>> flash2 00000000005383C6 Unknown Unknown
>> Unknown
>> flash2 00000000004D31E4 poisson_mg_relax_ 315
>> poisson_mg_relax.F90
>> flash2 00000000004D4DE9 poisson_mg_solve_ 38
>> poisson_mg_solve.F90
>> flash2 00000000004CA3C4 mg_cycle_ 82
>> mg_cycle.F90
>> flash2 00000000004CEEC8 multigrid_ 150
>> multigrid.F90
>> flash2 00000000004D249A poisson_ 87
>> poisson.F90
>> flash2 0000000000430CE6 modulegravpotenti 139
>> GravPotentialAllBlocks.F90
>> flash2 000000000042AF1B init_from_scratch 257
>> init_from_scratch.F90
>> flash2 000000000041D45A init_flash_ 324
>> init_flash.F90
>> flash2 000000000041C5BF MAIN__ 62
>> flash.F90
>> flash2 0000000000405362 Unknown Unknown
>> Unknown
>> libc.so.6 00007F7DBB0131C4 Unknown Unknown
>> Unknown
>> flash2 00000000004052A9 Unknown Unknown
>> Unknown
>>
>>
>>
>> * SEDOV EXPLOSION SETUP
>>
>>
>> [CHECKPOINT_WR] NOTE: will send 710 blocks per message.
>> [CHECKPOINT_WR] Writing checkpoint file sedov_hdf5_chk_0000
>> Progress: |
>> forrtl: severe (193): Run-Time Check Failure. The variable
>> 'perfmon_mp_log_timers_$CHECKPT_NUM' is being used without being defined
>> Image PC Routine Line
>> Source flash2 00000000005A1856
>> Unknown Unknown Unknown
>> flash2 00000000005A0A56 Unknown Unknown
>> Unknown
>> flash2 000000000055A646 Unknown Unknown
>> Unknown
>> flash2 0000000000522B81 Unknown Unknown
>> Unknown
>> flash2 00000000005241F6 Unknown Unknown
>> Unknown
>> flash2 00000000004CB301 perfmon_mp_log_ti 1067
>> perfmon.F90
>> flash2 0000000000465F75 checkpoint_wr_ 701
>> checkpoint_wr.F90
>> flash2 000000000045E2F6 output_initial_ 189
>> output_initial.F90
>> flash2 000000000041DB09 init_flash_ 335
>> init_flash.F90
>> flash2 000000000041CC33 MAIN__ 62
>> flash.F90
>> flash2 00000000004051E2 Unknown Unknown
>> Unknown
>> libc.so.6 00007F0BCE1FF1C4 Unknown Unknown
>> Unknown
>> flash2 0000000000405129 Unknown Unknown
>> Unknown
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Chris Daley wrote:
>>> Hi Seyit,
>>>
>>> I fully agree with Carlo's recommendation - Valgrind is an excellent
>>> tool. However, before resorting to such a powerful tool, it may be
>>> worthwhile using your compiler to detect uninitialised data. I notice
>>> that you have the intel compiler on two of your computing platforms.
>>>
>>> Try adding "-check uninit" and "-traceback" to your Fortran
>>> (debug) compilation options. This will check if an uninitialised
>>> variable
>>> is used in a calculation, and will generate a runtime error if it is
>>> used.
>>>
>>> I've just run a mini test in which I used a variable in my
>>> Simulation_initBlock.F90
>>> that is never initialised. Here is the output:
>>>
>>> forrtl: severe (193): Run-Time Check Failure. The variable
>>> 'simulation_initblock_$PP' is being used without being defined
>>> Image PC Routine Line
>>> Source
>>> flash3 00000000006B010B Unknown Unknown
>>> Unknown
>>> flash3 00000000006AE446 Unknown Unknown
>>> Unknown
>>> flash3 00000000006878DE Unknown Unknown
>>> Unknown
>>> flash3 000000000065CEB2 Unknown Unknown
>>> Unknown
>>> flash3 000000000065D147 Unknown Unknown
>>> Unknown
>>> flash3 000000000049D3DC simulation_initbl 88
>>> Simulation_initBlock.F90
>>> flash3 000000000044F05B Unknown Unknown
>>> Unknown
>>> flash3 000000000040E152 Unknown Unknown
>>> Unknown
>>> flash3 000000000041211D Unknown Unknown
>>> Unknown
>>> flash3 0000000000404A6A Unknown Unknown
>>> Unknown
>>> libc.so.6 000000355501C3FB Unknown Unknown
>>> Unknown
>>> flash3 00000000004049AA Unknown Unknown
>>> Unknown
>>> p0_31573: p4_error: interrupt SIGx: 13
>>>
>>> Remember to compile your code in "debug" mode, i.e. to
>>> include the -g compilation flag and no optimisations.
>>>
>>> You may also want to look at the option "-ftrapuv" which initialises
>>> local stack variables to "unusual values". Further information about
>>> all of these options can be found in the intel man page.
>>>
>>> Regards,
>>> Chris
>>>
>>>
>>> Carlo Graziani wrote:
>>>> Hi Seyit.
>>>>
>>>> Nathan's suggestion of investigating un-initialized variables use
>>>> and erratically allocated/deallocated memory is very sensible for
>>>> tracking down a problem that manifests itself as unpredictable
>>>> behavior.
>>>>
>>>> There is actually an open-source tool for doing this called valgrind.
>>>> It may already be installed on your local linux systems, and if not it
>>>> is easy enough to obtain.
>>>>
>>>> One runs a program under valgrind very simply (the documentation gives
>>>> more options):
>>>>
>>>> Prompt> valgrind <program-name> <program arguments>
>>>>
>>>> Then one sits back and digests the potentially-voluminous output.
>>>>
>>>> Valgrind will flag any access to uninitialized memory and
>>>> memory-management
>>>> screw-ups.
>>>>
>>>> Caveats are: (1) It's slow;
>>>>
>>>> (2) You'd be amazed at how much valgrind finds distasteful in system
>>>> libraries. You'll probably have to filter away a bunch of
>>>> uninteresting
>>>> warnings about libc/mpi/hdf5 and so on (which are probably harmless,
>>>> and which you can't do much about anyway). Valgrind has some
>>>> facilities
>>>> for suppressing certain types of warnings, which you can use to cut
>>>> down
>>>> the noise.
>>>>
>>>> If you can make a small version of the problem, running on one
>>>> processor, that
>>>> exhibits the erratic behavior, this would probably be an ideal case to
>>>> feed to valgrind. There's some support for parallel debugging, but
>>>> you'd probably
>>>> have to spend some quality time with documentation and haunt some
> other
>>>> mailing lists to get that running.
>>>>
>>>> Cheers,
>>>>
>>>> Carlo
>>>>
>>>> Nathan Hearn wrote:
>>>>> Hi Seyit,
>>>>>
>>>>> An uninitialized variable is one that is declared (specified as
>>>>> integer, real, etc.), but not assigned a value. Thus, an
>>>>> uninitialized variable usually has whatever value was in its memory
>>>>> location before it was declared. (It could be a random number,
>>>>> "infinity," or just garbage.) If this variable gets used before a
>>>>> value is assigned to it, strange behavior may result, which would be
>>>>> very compiler- and architecture-specific). If you are using
>>>>> uninitialized pointer or allocatable variables, the effects can be
>>>>> quite drastic and hard to identify.
>>>>>
>>>>> Generally speaking, it is a good idea to assign a value to every
>>>>> variable soon after it is declared, even if it is only a temporary
>>>>> value that is not actually used. (As I recall, there is a way to
>>>>> assign a null value to pointers, which is also a very useful
>>>>> practice.)
>>>>>
>>>>>
>>>>> - Nathan
>>>>>
>>>>>
>>>>> On 8/4/08, Seyit Hocuk <seyit at astro.rug.nl> wrote:
>>>>>> Hi Paul, hi Nathan,
>>>>>>
>>>>>> First of all; using --with-default-api-version=v16 when configuring
>>>>>> hdf5-1.8.1 works fine. Thanks for that Paul.
>>>>>>
>>>>>> Nathan, if you mean by uninitialized that the types are not defined
>>>>>> (like in config file REAL or INTEGER or whatever), then no because I
>>>>>> define them all. But if you mean I have included modules or
>>>>>> parameters
>>>>>> which I don't use, that's correct and I am no expert in
>>>>>> programming so
>>>>>> it might indeed be good to check this.
>>>>>>
>>>>>> Greetz,
>>>>>> Seyit
>>>>
>>>>
>>>
More information about the flash-users
mailing list