John Peterson schrieb:
On Fri, Mar 7, 2008 at 2:46 AM, Jan Biermann <[EMAIL PROTECTED]> wrote:
Hey all,
sorry in advance for bothering you with probably a stupid question but I
am just confused by the following problem:
I performed a simulation using a mesh with infinite elements and all is
fine. then I want to do some post-processing (getting the solution on
several single points in the computational domain) but all of a sudden I
get an error from the compute_map() function saying "negative Jacobian".
First thing is that the simulation worked fine without errors so the
mesh should be ok. Furthermore, it makes a difference if I read the
simulation mesh for the post-processing (that I wrote during the
simulation after building the infinite elements) or if I read just the
fe-mesh and reconstruct the final mesh by building the IFE in the
Out of curiosity, what file format are we talking about here? xda?
Sounds like the error is in reading a mesh that has IFEs, not one with
FEs only. I don't have experience with either.
Yes, I am using the xda format. it cannot be simply a reading error
because the same happens if I read a FE-mesh and build the IFE in the
post processing code (I wrote the mesh after that and compared the
simulation mesh from the simulation that includes the IFE with the one
that comes from the post processing- and they are exactly identical)
post-processing code (the result is the same mesh). The error then pops
up for different elements. When I dump on the screen all the values that
are computed for the jacobian in "compute_map()" I always get "nan" and
Wait, you are getting NaN for *every* element until you eventually get
a negative Jacobian? It sounds like the whole mesh may have trouble
and not just one element. Any idea if the neg. Jacobian is coming
from a regular geometric finite element or an infinite element?
all the element we are talking about are infinite elements.
all of a sudden a number other than "nan" is computed which is negative
and causes the error. But like I said, using the "read in" mesh a
certain element causes a "nan" (and hence, no error message) and the
same element causes a negative value and the error when the IFE are
build in the post-processing code. This all makes no sense to me.
Sounds like it must be a problem with the post-processing code. Also,
I'm curious how you know it is the "same" element both times. Same
connectivity? Is it possible some of the nodes were renumbered? A
common way for a negative Jacobian to pop up is for the order of two
nodes in the connectivity list to be transposed, effectively inverting
the element.
I know that it is the same element because I am writing the element
center coordinates and here I can see that one time the jacobian is NaN
and the next time something negative. I did no renumbering and I think
it didn`t happen by accident either because (like I said before) I
compared the mesh files and they match exactly.
(especially why in general a Jacobian=nan is computed).
I hope this was not too confusing and stupid.
Definitely confusing, but we won't know if it's stupid until we find
the bug :-) I am in agreement with Ben here, if possible could you
see if you could reproduce the problem on a mesh with one or two
elements?
Thanks a lot for the fast response! I will try to see if I can reproduce
that with a small model.
Jan
-John
Thanks in advance for your help,
Jan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
begin:vcard
fn:Jan Biermann
n:Biermann;Jan
org:;Institute for Modelling and Computation
adr;quoted-printable;dom:;;Denickestra=C3=9Fe 17;Hamburg;;21073
email;internet:[EMAIL PROTECTED]
title:Dipl.-Ing.
tel;work:+4940428784480
url:http://www.mub.tu-harburg.de
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
