-
-
Notifications
You must be signed in to change notification settings - Fork 86
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
Generic writer/reader for volume coupling #279
Comments
Hello. After talking with @MakisH I have tried to replicate the structure of the CHT/Temperature.C file in the FSI/Force.C file, since the chanel-transport tutorial is the closest to what I want to do. It compiles correctly so from a machine point of view it seems to be fine. I have created a simple case from the perpendicular-flap tutorial for testing. Where I create a openFOAM case with a porous medium in the middle of the domain. Also I modified the structural case made also in openFOAM to set the flap in the same position of the porous medium. Could you give me a path to follow and go fordward in this project? Thank you in advance |
@sroget could you please link to your code? You can fork this repository and push to a branch. I am not sure I understand what you have done. Which branches of the adapter are you based upon? We have not yet merged the volume coupling related changes (see #255 and #270, as well as precice/tutorials#315).
Try checking where this force field comes from. For surface coupling, we are computing the forces explicitly in the adapter (that's why you also need to provide a density in the I am not sure if or how we can access fields computed by other function objects, but we had such an idea before. Related: #143 I assume one would need to remove our own forces calculation and then check for forces objects registered in the OpenFOAM Objects Registry. |
Thank you very much for your time @MakisH . I am sorry for not expressing correctly what I have done. I will try to write it better. Summary And I have followed two paths: 1 Path: Modify FSI/Forces1.1 First I tried to run preCICE modifying only precicedict as in the tutorial channel-transport with openfoam. In the following image you can see the expected error.1.2 Modify FSI/Forces file to avoid the error. The code compiles but I get a Force field that does not read the forces that I am able to get through functionObject.1.3 I modify functionObject/force --> functionObject/myForce to save the forces produced by the porous medium to try to visualize in paraview how it should look like. I only modified NO_WRITE to AUTO_WRITE.At this point preCICE still gives me an empty force field. I don't know how to solve this and stop here. In the following image you can see what I get with the functionObject/myForce 2 Path:Create FSI/porousForce2.1 I copy VV/Velocity and modify it to get a file called porousForce that does not give errors when I compiled it.2.2 I run it to see what happens. It does not detect that there is a vectorField other than U.2.3 I try to modify porousForce with no progress, the best I get back was an empty field as in 1.2.As I see it I am not able to read the result of functionObject/myForce and send it to the structural solver. How can I do this? Also It seems that myForce is not saved in the ObjectRegistry I will see how can I do that: --> Done. My files are in Sergio-openfoam-adapter inside the fork of this issue. You have the test case and the FSI with the files that I modified
|
Thanks for the details! Link to your fork: https://github.com/sroget/openfoam-adapter Note that it does not look like the code would compile the changes from https://github.com/sroget/openfoam-adapter/tree/develop/Sergio-openfoam-adapter (the The error you get ( |
In the context of #255, we discussed whether a generic reader/writer would make sense (@tirgendetwas). An additional use case (as discussed with Sergio Roget at the preCICE Workshop 2023) would be coupling forces over a porous medium. These forces should already be available in the objects registry, so a generic reader/writer should be able to access it.
To make it very generic, we could use a template for any (or even constrained) type.
Later on, we could also add a generic reader/writer for surface fields.
Potentially also related to #277 and related to #77, #150.
The text was updated successfully, but these errors were encountered: