|
[Sponsors] |
November 17, 2006, 05:12 |
Hi,
I have got a problem ca
|
#1 |
Guest
Posts: n/a
|
Hi,
I have got a problem calculate my case. Every time I start the calculation the system is freezed in the first time step. I have to unplug the PC and then start it again. I cannot kill the calculation process. I really don't know how to solve this problem. There are no error messages in the log-file. Thanks a lot Christian |
|
November 17, 2006, 05:36 |
I assume this is a standard ap
|
#2 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
I assume this is a standard application, non-parallel and you don't run out of memory? Run memtest86 for a while or try running valgrind on the application.
|
|
November 17, 2006, 09:16 |
"I cannot kill the calculation
|
#3 |
Senior Member
Srinath Madhavan (a.k.a pUl|)
Join Date: Mar 2009
Location: Edmonton, AB, Canada
Posts: 703
Rep Power: 21 |
"I cannot kill the calculation process."
Can't you even access a virtual terminal (Ctrl + Alt + F1) and try to login from there. Sounds very strange, unless of course you have hardware issues. |
|
November 21, 2006, 11:18 |
I was not able to access a vir
|
#4 |
Guest
Posts: n/a
|
I was not able to access a virtual terminal. I run memtest86 on my workstation and the system got freezed. After this I want to check the settings in bios, but I was not able to enter it (only get to the exit page of bios). There was no password request and there was no password set until now. I reseted the bios (take out the battery for a moment) and was not able to boot any more.
Due to the service contract the mainboard will be changed tomorrow. I hope this will solve the problem. Thank you for you quick reply |
|
November 28, 2006, 11:09 |
The Mainboard was changed last
|
#5 |
Guest
Posts: n/a
|
The Mainboard was changed last week and I did some hardware testing. And everything looked alright, except that ecc was not enabled in linux. ecc works in winxp and is enabled in bios.
I don't know how to get this working. I run buoyantFoam (standard application, non-parallel and memory 3GB used (4GB ram 10GB swap installed)) and it crashed again. So I used valgrind and this is the beginning of the output: valgrind --leak-check=yes buoyantFoam /home/hausmann/OpenFOAM/hausmann-1.3/run/tutorials/buoyantFoam test ==4037== Memcheck, a memory error detector. ==4037== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==4037== Using LibVEX rev 1658, a library for dynamic binary translation. ==4037== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==4037== Using valgrind-3.2.2.SVN, a dynamic binary instrumentation framework. ==4037== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==4037== For more details, rerun with: -v ==4037== /*---------------------------------------------------------------------------*\ | ========= | | | \ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \ / O peration | Version: 1.3 | | \ / A nd | Web: http://www.openfoam.org | | \/ M anipulation | | \*---------------------------------------------------------------------------*/ Date : Nov 28 2006 Time : 15:53:42 Host : MTBH10 PID : 4037 Root : /home/hausmann/OpenFOAM/hausmann-1.3/run/tutorials/buoyantFoam Case : test Nprocs : 1 ==4037== Conditional jump or move depends on uninitialised value(s) ==4037== at 0x5C6B9EA: Foam::fileName::ext() const (in /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linuxAMD64Gcc4DPOpt/libOpenFOAM.so) ==4037== by 0x5C3BB8C: Foam::readDir(Foam::fileName const&, Foam::fileName::Type, bool) (in /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linuxAMD64Gcc4DPOpt/libOpenFOAM.so) ==4037== by 0x5CB1F76: Foam::Time::findTimes(Foam::fileName const&) (in /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linuxAMD64Gcc4DPOpt/libOpenFOAM.so) ==4037== by 0x5CA7C84: Foam::Time::times() const (in /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linuxAMD64Gcc4DPOpt/libOpenFOAM.so) ==4037== by 0x5CB4323: Foam::Time::findInstance(Foam::fileName const&, Foam::word const&, Foam::IOobject::readOption) const (in /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linuxAMD64Gcc4DPOpt/libOpenFOAM.so) ==4037== by 0x5D4DE91: Foam::polyMesh::polyMesh(Foam::IOobject const&) (in /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linuxAMD64Gcc4DPOpt/libOpenFOAM.so) ==4037== by 0x4D0D578: Foam::fvMesh::fvMesh(Foam::IOobject const&) (in /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linuxAMD64Gcc4DPOpt/libfiniteVolume.so) ==4037== by 0x413AB3: main (in /home/hausmann/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxAMD64Gcc4DPOpt/buoyan tFoam) ==4037== Warning: set address range perms: large range 111423312 (undefined) ==4037== Warning: set address range perms: large range 111423312 (undefined) ==4037== Warning: set address range perms: large range 108224976 (undefined) ==4037== Warning: set address range perms: large range 108225008 (noaccess) It is still working and there a lot of Warning: set address.... According to the manual of valgrind these Warning assume no error of OpenFOAM. But I don't know what's wrong with the conditional jumps. Hope you can figure the problem out. |
|
November 28, 2006, 13:54 |
>I run memtest86
- I assume
|
#6 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
>I run memtest86
- I assume that memtest now runs fine? - the .ext() warning in valgrind is a familiar one. Only happens in 64bit mode. Looks like bug in valgrind since I cannot see any problem in the code itself. - Is problem related to buoyantFoam (try another solver) or to the amount of memory (3Gb is on the edge of 32/64 bit addressing - does a smaller case run?) |
|
November 30, 2006, 06:25 |
Now the calculation finished w
|
#7 |
Guest
Posts: n/a
|
Now the calculation finished with following error summary:
==30912== ERROR SUMMARY: 32 errors from 1 contexts (suppressed: 2 from 1) ==30912== malloc/free: in use at exit: 133,525 bytes in 1,721 blocks. ==30912== malloc/free: 11,092,929 allocs, 11,091,208 frees, 235,424,720,535 byte s allocated. ==30912== For counts of detected errors, rerun with: -v ==30912== searching for pointers to 1,721 not-freed blocks. ==30912== checked 964,656 bytes. ==30912== ==30912== ==30912== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 160 of 297 ==30912== at 0x4A20858: malloc (vg_replace_malloc.c:149) ==30912== by 0x64996CB: nss_parse_service_list (in /lib64/libc-2.4.so) ==30912== by 0x6499E35: __nss_database_lookup (in /lib64/libc-2.4.so) ==30912== by 0x738D4FF: ??? ==30912== by 0x738E130: ??? ==30912== by 0x645CE1A: getpwuid_r@@GLIBC_2.2.5 (in /lib64/libc-2.4.so) ==30912== by 0x645C71E: getpwuid (in /lib64/libc-2.4.so) ==30912== by 0x5C39E16: Foam::userName() (in /home/hausmann/OpenFOAM/OpenFOAM -1.3/lib/linuxAMD64Gcc4DPOpt/libOpenFOAM.so) ==30912== by 0x5C56457: Foam::argList::argList(int&, char**&) (in /home/hausm ann/OpenFOAM/OpenFOAM-1.3/lib/linuxAMD64Gcc4DPOpt/libOpenFOAM.so) ==30912== by 0x413617: main (in /home/hausmann/OpenFOAM/OpenFOAM-1.3/applicat ions/bin/linuxAMD64Gcc4DPOpt/buoyantFoam) ==30912== ==30912== ==30912== 21,553 bytes in 483 blocks are possibly lost in loss record 297 of 297 ==30912== at 0x4A21069: operator new(unsigned long) (vg_replace_malloc.c:167) ==30912== by 0x6004D80: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&) (new_allocator.h:88) ==30912== by 0x6005CA4: char* std::string::_S_construct(char con st*, char const*, std::allocator const&, std::forward_iterator_tag) (basic _string.tcc:150) ==30912== by 0x6005E81: std::string::string(char const*, std::allocator const&) (basic_string.h:1449) ==30912== by 0x5DE9251: __static_initialization_and_destruction_0(int, int) ( in /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linuxAMD64Gcc4DPOpt/libOpenFOAM.so) ==30912== by 0x5DE9721: (within /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linu xAMD64Gcc4DPOpt/libOpenFOAM.so) ==30912== by 0x5C302F2: (within /home/hausmann/OpenFOAM/OpenFOAM-1.3/lib/linu xAMD64Gcc4DPOpt/libOpenFOAM.so) ==30912== ==30912== LEAK SUMMARY: ==30912== definitely lost: 52 bytes in 1 blocks. ==30912== indirectly lost: 240 bytes in 10 blocks. ==30912== possibly lost: 21,553 bytes in 483 blocks. ==30912== still reachable: 111,680 bytes in 1,227 blocks. ==30912== suppressed: 0 bytes in 0 blocks. ==30912== Reachable blocks (those to which a pointer was found) are not shown. ==30912== To see them, rerun with: --show-reachable=yes Then I executed the cavity-case with icoFoam and hotRoom with buoyantFoam. I started them via valgrind. cavity finished with 26 errors. It worked correct when I made the tutorials. So I removed the OpenFOAM installation and reinstalled it again. The same errors. I updated the kernel since the tutorials from 2.6.16.13 to 2.6.16.21. May this cause the error? I always closed memtest due to the not activ ECC. But after 1 Pass there are no errors. |
|
December 7, 2006, 13:10 |
Any suggestions? Is this a har
|
#8 |
Guest
Posts: n/a
|
Any suggestions? Is this a hardware problem? The workstation is new (Fujitsu Siemens celsius M440)! The same case is running on an other machine (Opteron 246). The same linux version (suse 10.1 64bit), the same kernel (2.6.16) the same OpenFOAM version (1.3), hardware is different.
I reinstalled linux on the celsius machine to exclude software issus, but the same error occured. I tried to run Linux and OpenFOAM via vmware on an winxp64 os (on the celsius machine) hoped to avoid hardware problems but this doesn't change anything. Considering all these facts I think it could be a driver or a software problem. The chipset of the celsius machine (intel g955x) is not known by linux. But I am just guessing. I have no idea about reason. Thanks for beeing so patient to solve my problem Christian |
|
December 7, 2006, 13:33 |
I had one of those Fujitsu mac
|
#9 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 |
I had one of those Fujitsu machines. Gave me a lot of trouble, had engineers around and after 3 visits he found a faulty memory chip. I threw it away and bought completely new memory. The machine is still alive and doing OK. From the symptoms, I wound't be surprised if you had a serious hardware problem.
Sorry, Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
OpenMPI causes system crash | wese | OpenFOAM Running, Solving & CFD | 0 | May 13, 2008 05:44 |
UDF and AMG solver crash | Josef | FLUENT | 2 | August 25, 2005 09:07 |
Unusual Crash | leon | Phoenics | 1 | December 6, 2001 07:12 |
track cause of crash | Matt | Phoenics | 2 | October 5, 2001 10:16 |
closed system calculation | Neil MacLeod | Main CFD Forum | 1 | May 13, 1999 16:47 |