Kratos: Condition and Element raises a KRATOS_ERROR_IF DomainSize < 0.0

[josep-m-carbonell]

This check is too restrictive and stops the calculation when this check is performed.
Can be changed to KRATOS_WARNING_IF ?

[loumalouomega]

Where?

[josep-m-carbonell]

Yes, this is performed in the Check method of the condition.h and element.h

[loumalouomega]

Well, when an element or condition is inverted the proper thing to do is stop simulation, in any case this decision should be taken by @KratosMultiphysics/technical-committee

[josep-m-carbonell]

just to give a example where it fails. This check use to be performed on the mesh elements supplied to Kratos, if the mesh contains a bad element, you get no result. It is better to get a bad result that no result. KRATOS_ERROR is something irreversible.

[loumalouomega]

I remember we change this because something, can you remember @jcotela ?

[maceligueta]

Sorry if I am adding noise to the discussion but... Shouldn't it be better to return some kind of error value to a higher level?
In case this is too disruptive, we could write the error details in some place so it can be checked from upper levels.
I agree with @josep-m-carbonell that there's no way back from a KRATOS_ERROR.

[josep-m-carbonell]

Maybe KRATOS_ERROR can be a logger severity without stopping the code, and add other severity, usually CRITICAL (that is also not stopping the code) and at the top FATAL (which raises an error stopping the execution). Adding only one or them can be enough.

The other thing is that if the label is ("") nothing is written, but if you add a single space (" ") then " : " is written as a output, this double point is a little bit artificial because you have not asked for it. I am for adding the possibility of using the logger without labels.

[roigcarlo]

@josep-m-carbonell The label has the intended behavior. ":" is written by default if the label is non empty, so you end up having something like that in the log:

Label: My output message

In the case you don't want the ":" you should provide an empty string as you point out. From C++, " " is non emty, so the colon is printed with an space as the label.

[RiccardoRossi]

KRATOS_ERROR does not go through the logger but through the exception system. we cannot change it without introducing a large performance impact.

would you be able to define the Check function for your own element avoiding the check done in the base element?

[loumalouomega]

I think that @RiccardoRossi is the easiest and less conflictive solution possible.

[josep-m-carbonell]

I don't need to open an issue to arrive to
this conclusion. I guess then that you are also not using this check in your elements...

[loumalouomega]

We are https://github.com/KratosMultiphysics/Kratos/blob/cc6050e11471a8b0b72173bab202827296eef70d/applications/StructuralMechanicsApplication/custom_elements/base_shell_element.cpp#L359

[josep-m-carbonell]

I have seen you pull request #2718. You don't have to use it because I said you are not using it... Take into account the problem I have exposed in the issue. Now you will introduce it in your element. It is a little bit contradictory because the solution proposed is exactly the contrary. To not use this check.

[RiccardoRossi]

just to clarify that i did not want to give a conflictive answer...

[loumalouomega]

I created #2718 because I saw that I wasn't using it in the base_solid_element that is one of most used elements. But for example it is used in the base_shell_element as I shown you

[jcotela]

If I understand this correctly, the problem here is ultimately the same as in #583: The element is currently not allowed to have zero or negative size, and the condition cannot have a negative size (but it can have size zero). This was discussed some time ago by the technical committee and it was agreed that it was too arbitrary. The proposed solution was to define a Check method in the geometries and allow each geometry to define what is a valid configuration, so that a point can have size zero but a triangle cannot have a zero or negative area. Unfortunately, this was considered relatively low priority and no implementation has been done so far.

@josep-m-carbonell would something like this work in your situation?

[josep-m-carbonell]

No, it is not the case. We encountered that a provided input mesh in 3D had a bad tetrahedron, the mesh algorithm could not give a better mesh with the imposed size constraints. The tolerance from the mesher gave that element as valid. However the check from kratos was giving an error and stopping the calculation. The "bad" element was located in a zone without incidence in the calculation, without the check you were able to compute the case and get a result, but with the added check (added last year) you get an error and no result. This is why I personally think that another type of error severity or a warning would be better.

[jcotela]

OK I see the point. The problem, as @RiccardoRossi was mentioning, is that the current design of the Check methods is based on throwing exceptions, rather than on the logger, so there is no severity to play with.

In any case (and this is probably a separate discussion), I see no problem with re-implementing the Check method on derived elements. The base class implementation is there to help in "standard" cases, not to impose additional requirements on derived elements. If your formulation supports elements with negative jacobians, I think it is fair to skip that check.

[josep-m-carbonell]

Dear @jcotela
The elements implemented in the applications I work with, are as much "standard" as others implemented in other applications.
If I open an issue to expose an encountered problem and the message in most of the responses of the thechnical committee are: "everything is right and must be like this"... It seems like... Well it's ok. Thank you for your response.

[philbucher]

I think this is solved
Please reopen if otherwise