-
-
Notifications
You must be signed in to change notification settings - Fork 93
Simplify error handling (remove error-deferred workaround) #364
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
base: develop
Are you sure you want to change the base?
Conversation
The system tests now pass: https://github.com/precice/openfoam-adapter/actions/runs/14307651426/job/40095066009?pr=364 Now only waiting for review. |
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.
Looks good, I didn't try to run it myself.
@@ -365,6 +366,8 @@ This directs the solver to use the `preciceAdapterFunctionObject` function objec | |||
which is part of the `libpreciceAdapterFunctionObject.so` shared library. | |||
The name `preCICE_Adapter` can be arbitrary. It is important that the library is loaded outside the `functions` dictionary when you want to use the custom boundary conditions that we provide with the FF module. | |||
|
|||
The `errors strict` option is optional and [available since OpenFOAM v2012](https://www.openfoam.com/news/main-news/openfoam-v20-12/post-processing#post-processing-function-object-error-handling). Since the adapter is necessary to do a coupled simulation, this option instructs OpenFOAM to stop in case it faces issues with loading the adapter. For OpenFOAM versions that don't support this, remove the option. |
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.
So, if not set, my OpenFOAM solver will just keep going, yes?
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.
Correct, same as when OpenFOAM cannot find the adapter.
Do you think this is particularly risky?
Should we take any further actions beyond mentioning this prominently in the changelog?
Currently, we have a workaround to force OpenFOAM to stop when encountering an error in the configuration phase. This is not needed anymore since OpenFOAM v2012, which introduces an additional option
errors
for the function object, which if set tostrict
, acts as we would expect in this scenario. See related OpenFOAM issue.The
errors
option is now in OpenFOAM long enough that we can assume we will not trouble too many users.This PR:
error-deferred
option fromUtilities.C
error-deferred
witherror
FataErrorInFunction
inUtilities.C
with aFatalError
(theFatalErrorInFunction
did not seem to work in some cases, and it does not seem appropriate for a central logging function)FatalErrorInFunction
with calls to theadapterInfo
function, clarifying the respective error messages, if needed.Ideally, I would go as far as to rename
adapterInfo
toadapterLog
, but this would touch too many files and potentially frustrate some users that maintain their own forks.I have tested the following:
patchName
readData
rho
-> a default OpenFOAM error is raised during the lookupReviewers: Filter out the whitespace changes. I indented-out a large part of
Adapter.C
because I removed a try-catch construct.TODO list:
docs/
changelog-entries/
(create directory if missing)