<div dir="ltr"><div><div><div>Klaus and Tomasz,<br><br></div>     It was indeed corrected by reducing the refinement. I had intended to not push up to 30 levels on this particular machine, and may have just run out of memory/procs. I am going to be using 30 levels soon however, and I'm assuming that the umap subroutines can handle these levels of refinement (when I have the requisite memory/procs)?<br><br></div>Thanks,<br><br></div>Josh<br><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 12:53 PM Klaus Weide <<a href="mailto:klaus@flash.uchicago.edu">klaus@flash.uchicago.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 23 Apr 2015, Joshua Wall wrote:<br>
<br>
> >     I'm receiving an odd error from FLASH and I'm not sure how to<br>
> > interpret it. Perhaps someone can enlighten me? Its:<br>
> ><br>
> >  **ERROR** - ierr from UMAPn is          421 , isg=           4<br>
> >  DRIVER_ABORT: ERROR - ierr from UMAPn is not 0<br>
<br>
The message indicates that the error occurs when interpolating data<br>
for block 4 (in some proc), and it is complainign about the X coordinate.<br>
<br>
As Tomek wrote, this may all be because of the high refinement level.<br>
Or...<br>
<br>
* Check your parfile, maybe xmin is the same as xmax? (forgotten /<br>
  duplicate sign ?)<br>
<br>
* Check that umap.F is compiled correctly, the compiler may somhow act<br>
  differently, this is about the only file that has a .F suffix instead<br>
  of .F90. In particular, check that flags promoting real to double<br>
  precision are there.<br>
<br>
Just some ideas.<br>
<br>
Klaus<br>
</blockquote></div></div>