New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MatrixFree: check that JxW is not negative #16317
base: master
Are you sure you want to change the base?
Conversation
@nfehn Could you check if this assert is triggered for your mesh? |
I think this is a very helpful check.
Yes, it is. |
@@ -2309,6 +2332,11 @@ namespace internal | |||
1. : | |||
my_data.descriptor[0].quadrature.weight(q)); | |||
|
|||
#ifdef DEBUG | |||
for (unsigned int v = 0; v < n_lanes_d; ++v) | |||
Assert(JxW[v] > 0.0, ExcInternalError()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wondered whether this exc message is clear, i.e. points to an invalid Jacobian determinant on faces? One might argue that JxW is basic FE language, so this is probably a matter of taste.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this message should ever trigger, as opposed to the one in line 1254 above, because JxW
is computed as
JxW = boundary_form.norm() * my_data.descriptor[0].quadrature.weight(q);
so here we have a norm that cannot be negative and a quadrature weight that should be non-negative. So here I would guess it is ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kronbichler Thank you for the explanation! But the value could be 0, couldn't it? Furthermore, the check for the cell not only checks whether the value is positive but also that it is not too small. Unfortunately, I could not find such a check for faces in MappingQ
(maybe I missed it).
Should we remove this assert? The chance is quite high that assert for the cell is triggered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is a check for the faces in terms of "sufficient" positivity. I would personally choose something like the other assertion you introduced above, with the difference to use Utilities::fixed_power<dim-1>(edge_length)
, i.e., one power less. It can trigger for really anisotropic faces (aspect ratio larger than 1e5), but I think that is ok.
@@ -1152,10 +1152,12 @@ namespace internal | |||
typename VectorizedDouble> | |||
void |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When looking at the code, I realized that the documentation for the other function below (dealing with faces), see comment https://github.com/dealii/dealii/pull/16317/files#r1413627125, seems to be the same as here for the cells? This could be something one wants to change in the future. Of course this is somewhat unrelated to the present PR.
/rebuild |
8098898
to
9356cc7
Compare
@kronbichler Do you have an idea why |
In a follow-up PR, I would like to extend it like
dealii/source/fe/mapping_q.cc
Lines 932 to 936 in 9042b92
But for that I access to the cells.