Hi Josh,<br><br>Can you send me your files for this case.  (.map, .rea, .usr, and SIZE).  I think you are probably right about the geometry being the issue, possibly the boundary conditions.  I will take a look at it and see if anything sticks out or if we can reproduce the problem locally.<br>

<br>Also, how did you create the mesh for this case?<br><br>Thanks,<br>Katie<br><br><div class="gmail_quote">
On Thu, Jun 2, 2011 at 1:16 PM,  <span dir="ltr"><<a href="mailto:nek5000-users@lists.mcs.anl.gov" target="_blank">nek5000-users@lists.mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


Hello Aleks,<br>
<br>
I compiled with the option for trapping a floating point exception,<br>
and it gives the message that it trapped the exception in the same<br>
spot as before (which is very odd).<br>
<br>
It might be worth mentioning that if I run in post-processing mode<br>
(nsteps=0), it still traps an exception while in userchk (although I<br>
don't think it's anything specific in my userchk, as I've used the<br>
same .usr file before).  The floating point exception occurs when I<br>
make a call to col3 with vx and vx (to get the velocity squared), but<br>
when I calculate the max and min velocities earlier in userchk, I<br>
don't have any issues.<br>
<br>
My guess is that something with my geometry is wrong, but it passes<br>
the various geometry checks I see in the logfile.  I'm not sure what<br>
is causing the failure at this point--any thoughts?<br>
<br>
Josh<br>
<div><div></div><div><br>
On Wed, Jun 1, 2011 at 6:38 PM,  <<a href="mailto:nek5000-users@lists.mcs.anl.gov" target="_blank">nek5000-users@lists.mcs.anl.gov</a>> wrote:<br>
> Hi Josh,<br>
><br>
> Have you tried to compile with trapping floating point exception?<br>
><br>
> E.g., the compiler flag for pgf77 is<br>
><br>
> -Ktrap=fp<br>
><br>
> Then you may get a better idea where Inf & Nan first appear...<br>
><br>
> Best,<br>
> Aleks<br>
><br>
><br>
><br>
> On Wed, 1 Jun 2011, <a href="mailto:nek5000-users@lists.mcs.anl.gov" target="_blank">nek5000-users@lists.mcs.anl.gov</a> wrote:<br>
><br>
>> Hello Neks,<br>
>><br>
>> I've recently come across an error I haven't seen before.    It occurs<br>
>> in the routine "generalev" at the beginning of my run.<br>
>><br>
>> It looks like the matrix "a" and "b" being fed to the routine have an<br>
>> Infinity or NaN at position (0,0).  Are there any ideas of what could<br>
>> cause this type of error?<br>
>><br>
>> I have attached the logfile to this email.<br>
>><br>
>> Thanks,<br>
>><br>
>> --<br>
>> Josh Camp<br>
>><br>
>> "All that is necessary for the triumph of evil is that good men do<br>
>> nothing" -- Edmund Burke<br>
>><br>
> _______________________________________________<br>
> Nek5000-users mailing list<br>
> <a href="mailto:Nek5000-users@lists.mcs.anl.gov" target="_blank">Nek5000-users@lists.mcs.anl.gov</a><br>
> <a href="https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users</a><br>
><br>
<br>
<br>
<br>
--<br>
Josh Camp<br>
<br>
"All that is necessary for the triumph of evil is that good men do<br>
nothing" -- Edmund Burke<br>
_______________________________________________<br>
Nek5000-users mailing list<br>
<a href="mailto:Nek5000-users@lists.mcs.anl.gov" target="_blank">Nek5000-users@lists.mcs.anl.gov</a><br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users</a><br>
</div></div></blockquote></div><br>