<div dir="ltr">Hi Klaus,</div>
<div dir="ltr"><br> </div>
<div dir="ltr">When I increased the number of process to 32 and decreased nend to 3000, it works without any problem and the run successfully completed, reaching to 109ps. However, when I only changed Cu temperature from 25 eV to 50 eV, the problem occurs again. Any ideas?</div>
<div dir="ltr"> </div>
<div dir="ltr">Thanks,</div>
<div dir="ltr">Reem<br></div>
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><br>------------------------------<br><br>Message: 2<br>Date: Fri, 16 Aug 2013 15:47:51 -0500 (CDT)<br>From: Klaus Weide <<a href="mailto:klaus@flash.uchicago.edu" target="_blank">klaus@flash.uchicago.edu</a>><br>
Subject: Re: [FLASH-USERS] Timing problem in LaserSlab example<br>To: Reem Alraddadi <<a href="mailto:raba500@york.ac.uk" target="_blank">raba500@york.ac.uk</a>><br>Cc: <a href="mailto:flash-users@flash.uchicago.edu" target="_blank">flash-users@flash.uchicago.edu</a><br>
Message-ID: <<a href="mailto:Pine.LNX.4.64.1308161521420.24703@flash.uchicago.edu" target="_blank">Pine.LNX.4.64.1308161521420.24703@flash.uchicago.edu</a>><br>Content-Type: TEXT/PLAIN; charset=US-ASCII<br><br>On Fri, 16 Aug 2013, Reem Alraddadi wrote:<br>
<br>> Hi all,<br>><br>> I am running a Modified LaserSlab example for three materials with the<br>> following setup line:<br>><br>> Slab3 -2d +pm4dev -nxb=16 -nyb=16 +mtmmmt +mgd species=cham,targ,foil<br>
> mgd_meshgroups=6 -parfile=example.par +3t -maxblocks=1000<br>><br>> the run goes OK at the first time with lrefine_max=6 but when I goes<br>> with lrefine_max=9<br>> I got the following warning message :<br>
><br>> Warning: The initial timestep is too large.<br>><br>> initial timestep = 1.000000000000000E-014<br>><br>> CFL timestep = 5.139420973957487E-014<br>><br>> Resetting dtinit to TIMESTEP_SLOW_START_FACTOR*dtcfl.<br>
<br>[...]<br><br>> So I reduced the initial time step and made dtinit=dtmin=0.1e-14 and I<br>> increased nend to 8000 as I am really interested in time when it reaches to<br>> 50ps until 200ps. However, by doing that , the warning message does not<br>
> exist any more but ...<br><br>Reem,<br><br>You did not necessarily have to modify dtinit, since (as the Warning<br>message tries to say) the initial dt was reset to 0.5139420973957487e-14<br>automatically. (I believe TIMESTEP_SLOW_START_FACTOR is hardwired to 0.1.)<br>
It is good that you decreased dtmin. It may also be good that you<br>decreased dtinit to below that automatic value.<br><br>However, those things are probably unrelated to the ultimate failure of<br>your runs.<br><br>> I found the run didn't complete and just reach when<br>
> t=5e-11 and n step was only 1809 . Also, I found an output file regard to<br>> Hypre library which I didn't understand what does mean. I have attached<br>> with this e-mail my flash.par file, out.log, lasslab.log and the output<br>
> messages regard to Hpyre file. I need my run reach to time from 50ps until<br>> 200 ps. Could you help me with this, please?<br><br>It seems you got to ~ 53 ps. Then the run(s) failed.<br><br>You did not provide the contents of the err.err file, even though<br>
your output.log says (twice):<br><br> PS:<br><br> Read file <err.err> for stderr output of this job.<br><br>Maybe there are some messages in that file explaining while the run(s)<br>failed.<br><br>You may have exceeded the allowed CPU time in your batch system, or may<br>
have run out of memory, or some similar reason.<br><br>> PS: the flash,par is as same as example.par. Also,I wonder if the problem<br>> because I run the same problem twice. I found that by mistake I run the<br>> same file twice. Is this the reason that the run didn't complete ?<br>
<br>I don't know. But it seems you had two instances of the same simulation<br>running in the same directory, overwriting each other's output files<br>and both writing interspersed lines to the log file. It is unnecessarily<br>
difficult to analyze from this output what has actually happened.<br><br>I would suggest you<br> * restart, making sure this time that only one instance of the code is<br> running.<br> * You may restart from a checkpoint instead of starting from step 1,<br>
to save time (you seem to have dumped checkpoints frequently).<br> * If the run fails again, make sure you look at all available output<br> including any err.err file.<br><br>> and what<br>> does hypre message mean?<br>
<br>Apparently the run (or at least one of them? - it is unclear whether<br>the hypre stack traces were generated by one or by both runs) died while<br>at least some processors where in a hypre function. It is unclear<br>
to me whether those processors actually caused signals that resulted in<br>aborting the runs.<br><br>Btw. it isn't clear what version of FLASH you were using. I hope you are<br>using 4.0.1, because it includes a hypre-related fix to 4.0.<br>
<br>Klaus<br><br><br>------------------------------<br><br>_______________________________________________<br>flash-users mailing list<br><a href="mailto:flash-users@flash.uchicago.edu" target="_blank">flash-users@flash.uchicago.edu</a><br>
<a href="http://flash.uchicago.edu/mailman/listinfo/flash-users" target="_blank">http://flash.uchicago.edu/mailman/listinfo/flash-users</a><br><br><br>End of flash-users Digest, Vol 70, Issue 8<br>******************************************<br>
</blockquote></div><br></div></div></div>