[FLASH-USERS] Problem with Compiling Flash3.0

Wed Jun 4 14:44:30 EDT 2008

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 <seyit at astro.rug.nl> 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.