Hi Luc, have a look at this thread, it might be related to your problem. I had a similar problem when I was trying to reload simulations from the triaxial test. ( http://www.mail-archive.com/[email protected]/msg04708.html)
Chiara On 26 November 2010 10:11, Luc Sibille <[email protected]> wrote: > Hi Nejib thank you for your reply. > > I don't make any modification of the xml. I just run a simulation, stop it > and save the xml file. Then reload the xml file and it is there that Yade > can't iterate with this reloaded xml file. I checked the xml file, it is > complete with the good lines at the end, at the beginning and so on. Of > course the xml is quite big: about 250 MB but it should not be a problem. I > verified this problem on several computers with different configurations > (Ubuntu, fedora ...) and I get it each time. > > There are several things like that quite strange when you save and reload a > xml file. As long as you don't reload a xml file the simulation works fine. > But when you reload a xml file, you can have as I explained memory problems, > or previous contact normal with one of the component being nan whereas none > of the current contact normal has a nan ... > > Luc > > Nejib Hadda a écrit : > > Hi Luc, >> >> I think you have a memory problem when loading the xml file, I don't >> know why yade developpers changed the craft in the xml file so that evry >> almost evry word takes one line. At first (when generating) your file >> can be loaded, but since interactions take place the xml file will >> increase in lines and system can not load it easily anymore. >> >> Another thing is that may be you made change on the xml file, but you >> did not wait untill it is fully loaded, then you saved a corrupted file, >> but I think it's not the because yade will crash. >> >> May be you can try something, launch YADE and then Go to the system >> monitor (equivalent to task manager on windows), click on the processus >> tab, and then right clik on yade and click on change priority, take a >> small value (hight priority), and click ok. >> >> load your file, once loaded, before running reset the priority to normal >> and then run your simulation. >> >> Hope this would be helpful ! >> >> >> Le jeudi 25 novembre 2010 à 18:52 +0100, Luc Sibille a écrit : >> >>> Hi everyone, >>> >>> After some Yade iterations (more than about 600 000) I save a xml. Then >>> when I reload this xml all is fine, but when I run the simulation, Yade is >>> not able to iterates: the ram memory used increases until having the >>> following message: >>> >>> Yade [1]: O.load('on_va_voir.xml') >>> Yade [2]: O.run() >>> Yade [3]: 117953 FATAL yade.ThreadRunner >>> /home/luc/Sim_DEM2/YADE_lbm/yade-0.50-lbm-dev_mainrepo/core/ThreadRunner.cpp:31 >>> run: Exception occured: >>> std::bad_alloc >>> >>> >>> I use Yade 0.50, I tried to run Yade throught Valgrind and here is the >>> result below. Have you got an idea where to look for to solve this problem? >>> >>> Thank you in advance, >>> >>> Luc >>> >>> >>> Yade [6]: O.run() >>> Yade [7]: **8588** new/new[] failed and should throw an exception, but >>> Valgrind >>> ==8588== at 0x402513F: VALGRIND_PRINTF_BACKTRACE (valgrind.h:4214) >>> ==8588== by 0x40256CC: operator new(unsigned int) >>> (vg_replace_malloc.c:255) >>> ==8588== by 0xC4F9325: >>> boost::shared_ptr<Interaction>::shared_ptr<Interaction>(Interaction*) >>> (shared_count.hpp:87) >>> ==8588== by 0xC4D7B20: >>> InsertionSortCollider::handleBoundInversion(int, int, InteractionContainer*, >>> Scene*) (InsertionSortCollider.cpp:45) >>> ==8588== by 0xC4DD9B8: InsertionSortCollider::action() >>> (InsertionSortCollider.cpp:282) >>> ==8588== by 0x5E93276: Scene::moveToNextTimeStep() (Scene.cpp:87) >>> ==8588== by 0x5E958D6: SimulationFlow::singleAction() >>> (SimulationFlow.cpp:18) >>> ==8588== by 0x5E8ABCB: ThreadWorker::callSingleAction() >>> (ThreadWorker.cpp:71) >>> ==8588== by 0x5E8E2DC: ThreadRunner::call() (ThreadRunner.cpp:53) >>> ==8588== by 0x5E92FB5: ThreadRunner::run() (ThreadRunner.cpp:27) >>> ==8588== by 0x5E9C41C: >>> boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, >>> boost::_mfi::mf0<void, ThreadRunner>, >>> boost::_bi::list1<boost::_bi::value<ThreadRunner*> > >, >>> void>::invoke(boost::detail::function::function_buffer&) >>> (mem_fn_template.hpp:49) >>> ==8588== by 0x5EEAD65: >>> boost::detail::thread_data<boost::function0<void> >::run() >>> (function_template.hpp:1013) >>> **8588** cannot throw exceptions and so is aborting instead. Sorry. >>> ==8588== at 0x402513F: VALGRIND_PRINTF_BACKTRACE (valgrind.h:4214) >>> ==8588== by 0x40256DA: operator new(unsigned int) >>> (vg_replace_malloc.c:255) >>> ==8588== by 0xC4F9325: >>> boost::shared_ptr<Interaction>::shared_ptr<Interaction>(Interaction*) >>> (shared_count.hpp:87) >>> ==8588== by 0xC4D7B20: >>> InsertionSortCollider::handleBoundInversion(int, int, InteractionContainer*, >>> Scene*) (InsertionSortCollider.cpp:45) >>> ==8588== by 0xC4DD9B8: InsertionSortCollider::action() >>> (InsertionSortCollider.cpp:282) >>> ==8588== by 0x5E93276: Scene::moveToNextTimeStep() (Scene.cpp:87) >>> ==8588== by 0x5E958D6: SimulationFlow::singleAction() >>> (SimulationFlow.cpp:18) >>> ==8588== by 0x5E8ABCB: ThreadWorker::callSingleAction() >>> (ThreadWorker.cpp:71) >>> ==8588== by 0x5E8E2DC: ThreadRunner::call() (ThreadRunner.cpp:53) >>> ==8588== by 0x5E92FB5: ThreadRunner::run() (ThreadRunner.cpp:27) >>> ==8588== by 0x5E9C41C: >>> boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, >>> boost::_mfi::mf0<void, ThreadRunner>, >>> boost::_bi::list1<boost::_bi::value<ThreadRunner*> > >, >>> void>::invoke(boost::detail::function::function_buffer&) >>> (mem_fn_template.hpp:49) >>> ==8588== by 0x5EEAD65: >>> boost::detail::thread_data<boost::function0<void> >::run() >>> (function_template.hpp:1013) >>> ==8588== >>> ==8588== HEAP SUMMARY: >>> ==8588== in use at exit: 761,091,121 bytes in 14,178,786 blocks >>> ==8588== total heap usage: 139,013,366 allocs, 124,834,577 frees, >>> 5,365,970,720 bytes allocated >>> ==8588== >>> ==8588== >>> ==8588== Valgrind's memory management: out of memory: >>> ==8588== newSuperblock's request for 56717312 bytes failed. >>> ==8588== 2883981312 bytes have already been allocated. >>> ==8588== Valgrind cannot continue. Sorry. >>> ==8588== >>> ==8588== There are several possible reasons for this. >>> ==8588== - You have some kind of memory limit in place. Look at the >>> ==8588== output of 'ulimit -a'. Is there a limit on the size of >>> ==8588== virtual memory or address space? >>> ==8588== - You have run out of swap space. >>> ==8588== - Valgrind has a bug. If you think this is the case or you >>> are >>> ==8588== not sure, please let us know and we'll try to fix it. >>> ==8588== Please note that programs can take substantially more memory >>> than >>> ==8588== normal when running under Valgrind tools, eg. up to twice or >>> ==8588== more, depending on the tool. On a 64-bit machine, Valgrind >>> ==8588== should be able to make use of up 32GB memory. On a 32-bit >>> ==8588== machine, Valgrind should be able to use all the memory >>> available >>> ==8588== to a single process, up to 4GB if that's how you have your >>> ==8588== kernel configured. Most 32-bit Linux setups allow a maximum >>> of >>> ==8588== 3GB per process. >>> ==8588== >>> ==8588== Whatever the reason, Valgrind cannot continue. Sorry. >>> l...@pc-calc-luc2:~$ >>> >>> >>> >> >> > -- > Luc Sibille > > Université de Nantes - Laboratoire GeM UMR CNRS > > IUT de Saint Nazaire > 58, rue Michel-Ange - BP 420 > 44606 Saint-Nazaire Cedex, France > > Tel: +33 (0)2 40 17 81 78 > > _______________________________________________ > Mailing list: > https://launchpad.net/~yade-users<https://launchpad.net/%7Eyade-users> > Post to : [email protected] > Unsubscribe : > https://launchpad.net/~yade-users<https://launchpad.net/%7Eyade-users> > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~yade-users Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
