You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I guess there was already an error/inaccuracy (compared to the FEniCS case) in how you are treating the boundary conditions before. I would suggest to open an issue and try to fix this to reach the same accuracy as for the FEniCS case without subcycling in a separate PR. Not sure whether this is actually possible with OpenFOAM: In FEniCS, I needed 2nd order FEM to do the trick with the flux. I have no idea about the capabilities of OpenFOAM and FV here.
The text was updated successfully, but these errors were encountered:
Let's not close this issue. The value of the case lies in the fact that you can compute the result at very high accuracy and spot errors in the adapter (or elsewhere) quickly by comparing to the analytical solution. Locating the source of the error is then a different story, but this case really helps to unit test the features of an adapter quite well if you pick the right settings.
I think this is something where we should sit down together since I'm lacking the OpenFOAM knowledge and I guess I could help you here with my knowledge about the numerics of the case. Let's see, if we find time for this during the next coding days.
Originally posted by @BenjaminRodenberg in #406 (review)
The text was updated successfully, but these errors were encountered: