Menu ▾ ▴

#51 Assessing the difficulty of porting block solvers to recent OpenFOAM

1.0
closed
Hrvoje Jasak
None
2020-07-24
2020-07-24
Elwardi Fadeli
No

Hello,

Up until now, I was using foam-extend4 as a base for my own libraries/solvers because of the block-coupling functionality. But of course, letting go of the most-recent OpenFOAM features (think: fvOptions) is not really an easy decision to make "just" because I need the block-coupled matrices and associated classes from Foam-Extend.

Hence, I'm considering rewriting ( or at least adapting as a first step) the block-coupled portion of "foam" and "finiteVolume" libraries so they work with OF7+ (planning on maintaining them).

To be honest, I'm in the planning phase and the idea looks pale to me at this point. I would like the foam-extend devs (if hey are interested) to share their insight on the following notes:

  1. I don't want to start working only to face a giant wall I can't pass; so, I'm poking around the code trying to figure out the most important (time-consuming) challenges.

I only found exactly one issue that can't be solved easily (from my own point of view), which is that GeometricField "type-uses" BlockLduInterfaceField !!! Check the attached images (gray arrows represent "type-usage" relationships and the blue ones stand for "(direct) use" relationships).

To be more specific, GeometricBoundaryField has blockInterfaces() which tails to BlockLduInterfaceField eventually (The second image gives the layout of GeometricBoundaryField).

Now, I know that GeometricField is closely tied to the other parts of the library; so rewriting this class is not really an option. My question is how feasible you think writing a child class (BlockGeometricField) which has block capabilities (I'm concerned about the usability of such class).

  1. In my analysis of both foam-extend side of things as well as the equivalent OpenFOAM libraries, I assumed that if I could reach a working state of "BlockLduSystem", the rest will be relatively easy!
    Is this assumption valid?

  2. I didn't analyze this enough, but I get the feeling that writing fvOptions for foam-extend would be harder (also, this is not the only feature I want from OF releases). Can anyone share his ideas on which road would be easier.

* By "easier" I mean "less time-consuming". I'm willing to learn whatever C++ concepts/techniques to achieve the goal :) *

Hope to hear from you soon

2 Attachments
boundaryclass.png
geomfield-blockinterface-type-usage.png

Discussion

  • Hrvoje Jasak

    Hrvoje Jasak - 2020-07-24

    Not a bug.

     

  • Hrvoje Jasak

    Hrvoje Jasak - 2020-07-24
    • status: open --> closed
    • assigned_to: Hrvoje Jasak
     

  • Hrvoje Jasak

    Hrvoje Jasak - 2020-07-24

    you are probably looking at Copyright violation as the biggest problem. Beware what you sign

     

  • Elwardi Fadeli

    Elwardi Fadeli - 2020-07-24

    I'm sorry I posted a not-a-bug issue without declaring it at the begining (Forgot to do so, and didn't know where else to post such an issue)

    "Copyright violation"? My Code will be GPLed and the original authors must take full credit on what they developed (At least, file authors and comments refering to people/orgs will be kept)!! Never crossed my mind to claim another's programmer's code as my own.

    Just curious: Am I still going into "Copyright violation" in this situation? If I am, could you please
    mention why? You made me doubt my self now! Is My small toolbox a copyright violation? That's the last thing I want to do to you guys!

    Starting to lose interest in the idea of the post though :(

     

Log in to post a comment.