<div dir="ltr">Wilke<div><br></div><div>If you use symmetry_rotating_180, then there cannot be any refinement boundaries that are too close to the symmetry boundary, hence there will be slightly larger fine grids.</div><div><br></div><div>-erik</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 12, 2019 at 1:46 PM Wilke van der Schee <<a href="mailto:wilke.van.der.schee@cern.ch">wilke.van.der.schee@cern.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">Dear Erik,<div><br></div><div>Thanks for the reply, such might indeed be the case. We use the same settings as in the gallery, i.e. a gridsize of 396 with dx=18 and then 7 levels of refinement. Could the symmetry also be of influence here? (both reflection_z and symmetry_rotating180 are used). Looking at the grid (it was attached as visit0000.png) it looks quite fine to me, but I don't have that much experience.</div><div><br></div><div>Thanks again, best,</div><div><br></div><div>Wilke</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 12 Mar 2019 at 18:38, Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Mar 12, 2019 at 11:26 AM Wilke van der Schee <<a href="mailto:wilke.van.der.schee@cern.ch" target="_blank">wilke.van.der.schee@cern.ch</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div dir="ltr">Dear users,<div><br></div><div>We have been trying for a while to get neutron star mergers for different equations of state, with only partial success. While the gallery example with the polytrope runs fine, we already encounter problems with the SLy_tabulated EOS. (we're using the current release, ET_2018_09)</div><div><br></div><div>One particularly puzzling error we don't understand is the following (full log+par file attached)</div><div><br></div><div><div>"INFO (NSTracker): Found star at (-10.125,-5.90625,0)</div><div> 21256 373.641 | 52.3035497 | 0.0001505 0.0053630 | 0.0014340 | 1.0717264 | 0.0019186 | 3591</div><div>INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 0</div><div>INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 1</div><div>WARNING level 1 from host n0086.compute.hpc process 0</div><div> while executing schedule bin (none), routine (no thorn)::(no routine)</div><div> in thorn CarpetLib, file /hpc/local/CentOS7/uu_itp_strings/Cactus/configs/sim/build/CarpetLib/dh.cc:161:</div><div> -> </div><div>/hpc/local/CentOS7/uu_itp_strings/Cactus/configs/sim/build/CarpetLib/dh.cc:980:</div><div> [ml=0 rl=6 c=0] The following grid structure consistency check failed:</div><div> Synchronisation and boundary prolongation: All points must have been received</div><div> needrecv.empty()</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>This is an internal error in Carpet. Most of the time, this indicates another error that wasn't caught properly before the details of the grid structure are generated. What resolution are you using? If you are using a resolution that is too coarse, then the refined regions don't fit into the simulation domain, and this could lead to such an error.<br></div><div><br></div><div>-erik</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>ml=0 rl=6</div><div>baseextent=([756,504,756]:[6408,11784,6408]:[4,4,4]/[189,126,189]:[1602,2946,1602]/[1414,2821,1414]/5640296116)" (shortened log attached, full log here: <a href="https://www.dropbox.com/s/avgrshl8chhzp6i/atmostr025full.out?dl=0" target="_blank">https://www.dropbox.com/s/avgrshl8chhzp6i/atmostr025full.out?dl=0</a>)</div></div><div><br></div><div>and then much more information about the grid structure (see full log). Indeed when looking into visit at this time the grid structure is a bit strange (also attached, at t=373.5, just before the crash). It containts the 3rd central mesh already, which is not really supposed to be triggered, but on the other hand that by itself should not lead to this crash (and I'm not quite sure why the trigger was activated at t=180).</div><div><br></div><div>The main difference of the parameter file wrt the gallery is of course the equation of state and hence the initial Lorene file. We also needed to go to dtfac=0.25 (otherwise even earlier con2prim errors appear), and for testing and stability purposes we now use an atmosphere density of 10^{-9}.</div><div><br></div><div>Any ideas how to look for more information or on similar problems would be very welcome, we do have more output files of course. Looking at the source code didn't help me much for now.</div><div><br></div><div>Many thanks in advance for suggestions,</div><div><br></div><div>Wilke van der Schee (post-doc Utrecht University)</div></div></div></div>
</div></div></div>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@einsteintoolkit.org" target="_blank">Users@einsteintoolkit.org</a><br>
<a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_4134737553116798515gmail-m_-8421167374627568573gmail_signature"><div dir="ltr"><div>Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div><div><br></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div><div><br></div></div></div>