<div dir="ltr"><div><div><div><div><div><div><div>Hi FLASH-users,<br><br></div>I am trying to perform the "Orbit" test problem that comes with FLASH4.2.2 to test Poisson solvers in simulations including particles.<br><br></div>I used the following setup command:<br></div>./setup Orbit -auto -3d<br><br></div>It compiled fine but crashed during runtime. The message dumped to stdout/stderr was:<br><br>DRIVER_ABORT: src == gr_meshMe, and we still have unmatched neData, bad<br></div><div><br></div><div>while the orbit.log file had:<br><br> [ 11-07-2017  15:38:20.889 ] step: n=440 t=1.756000E+03 dt=2.000000E+00<br> [ 11-07-2017  15:38:20.894 ] [DRIVER_ABORT]: Driver_abort() called by PE           0<br> [ 11-07-2017  15:38:20.895 ] abort_message: src == gr_meshMe, and we still have unmatched neData, bad<br><br></div><div>I managed to fix the issue by setting the logical parameter "regrid" to .false. in Particles_advance.F90 (as reminded by looking at a previous FLASH-USERS email), but I am concerned if this is an acceptable workaround. <br><br>Shouldn't particles that move off the block owned by its source processor need to have regrid=.true.? Would anyone be able to explain in more detail the purpose of having regrid=.true. or regrid=.false.<br></div><div><br></div></div>Thanks in advance for your help.<br><div><br></div><div>Best,<br clear="all"></div>--------<div><span class="gmail-il">Ryan</span> <span class="gmail-il">Farber</span><br></div><div>Graduate Student<br></div>University of Michigan, Ann Arbor<br><br></div>P.S. Thanks Klaus for responding to my last question! I greatly appreciate the help!<br clear="all">
</div>