-
Notifications
You must be signed in to change notification settings - Fork 15
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
stange error when compiling for compressibleInterFoam with OF v5 #4
Comments
You're very right to post this here, as I wouldn't have (ever) seen it on CFDOnline. The error seems to implicate that there are two different meshes. I reckon that's normal if you have something like dynamic mesh refinement (as in interDyMFoam), or if you're trying to couple particle-based methods (e.g., DSMC) and CFD. Or... perhaps this sort of error also appears when a volField is being assigned to a surField (or vice versa). Perhaps in compressibleInterFoam the fieldType is different...? Can you try to check the following:
|
Hi Kevin, Thank you for the super prompt reply! Yes, it seems that's what the error is suggesting, however, I have never come across this when using OpenFOAM before and I am not using any fancy meshing techniques, just a uniform grid. I am not trying to couple multiple methods either, so I find this error a bit perplexing. I'll have a go with your suggestions, however, to answer your questions:
In the posts relating to kva_interfaceProperties, I did read however of people managing to make this work for compressibleInterFoam, so perhaps something has changed in this version of OpenFOAM ? I'll try to find out more and get back to you. Thanks. Jacky. |
If that's the case, I'd try the following:
That could be the critical difference between interFoam and compressibleInterFoam, as in interFoam rho is computed from rho_1 and rho_2 (two scalars) using the alpha-field as weighting factor. Perhaps this causes the error, since "nHatf" is computed from the gradient of rho... Perhaps something goes wrong in that calculation, resulting in a different type of field, and hence the error. |
Hi Kevin, I will try asking the other users, hopefully they are as helpful as you are. I am getting a different error now (I deleted everything and recompiled from scratch. Again, kva_interFoam works fine, but not kva_compressibleInterFoam): This what I get upon trying to run the depthCharge2D tutorial (with the added entries in thermophysicalProperties):
I think this confirms that it is something related to rho, however I have absolutely no idea what N4Foam9rhoThermoE is. |
Regarding the first error you were getting: do you use densityWeighted=False? In that case, rho is not used explicitly in the curvature calculation of kva_interfaceProperties. Perhaps that gets rid of the error. I copy these links, such that I can easily open them again later, if I need to do further comparing: Getting a new error after recompiling is weird. That must imply you did something differently either the first time or the second time. What happens if you give it a third go? I don't know the origin of the second error. "Not allocated" seems to imply a programming error, but "rhoThermo" (or anything like that) is not part of kva_interfaceProperties. I reckon you're missing a dependency of compressibleInterFoam during compilation? Compare the make/files files of the original compressibleInterFoam and kva_compressibleInterFoam. |
Hi Kevin, Yes, the first error was obtained using densityWeighted set to "no". In any case, the default is set to false, right? So it shouldn't make much of a difference I believe. Previously I had compiled kva_interfaceProperties only for interFoam and interDyMFoam. I tried doing the same for compressibleInterFoam and compressibleInterDyMFoam in a separate directory, but it wasn't quite working well so I thought to restart from scratch with all kva_interfaceProperties linked to all 4 solvers at one go. I've checked the dependencies, and it look fine to me. Including these below for your info: kva_compressibleInterFoam make/options:
for the native compressibleInterFoam in /src, make/options:
|
Hi Kevin, A small update (also for future reference and as info to other users).
or the absolute path to kva_interfaceProperties? It seems that if I use ./Allget and ./Allmake I would get -I$(LIB_SRC)/transportModels/interfaceProperties/lnInclude . However, I tried manual compilation (I'm using a managed desktop) and if I use the absolute path to kva_interfaceProperties I get a missing dependency to surfaceTensionModel.H :
I'll post solution once resolved. |
That was a slip-up. It's the gradient of alpha: https://github.com/floquation/OF-kva_interfaceProperties/blob/of50/curvatureModel/vofsmooth/vofsmooth.C
An absolute or relative path does not matter. So that solves your latest "missing
Can you try setting the smoothing method to "normal" in |
I do remember someone had a weird error I could not explain in the past... That was with OF50, but regular interFoam if I recall correctly. |
Hi Kevin, Thank you for clarifying. However, this does not seem to be an issue for interFoam. For the record, in another error on the github page (#2 (comment)) step ii) says these two lines should be replaced so you might want to update that? My Make/options now looks like this:
which compiles successfully with no missing header files. However, trying to run this for the "normal" method still gives the error I quoted earlier:
I think I will try copying the entire solver source code and hope it works. I suspect I am messing something up in terms of dependencies. I do expect this to work as posts #38 to #44 in https://www.cfd-online.com/Forums/openfoam-verification-validation/124363-interfoam-validation-bubble-droplet-flows-microfluidics-2.html seem to suggest it is possible, although one user does point out persisting issues. I have messaged them privately like you suggested but so far no replies. Your help on this is very much appreciated, so thank you. |
I updated it.
Post #38:
I'll wait for that outcome. |
The curvature calculation in compressibleInterFoam is still the CSF model of Brackbill which is why I think it should work. I think I will leave OF40 as a last resort - given it is a managed desktop I would need to ask IT to have it installed on my desktop so ideally I would manage to get it work in OF50. I do have access to OF6, although it seems that this does not work for that version? So I copied everything in applications/solvers/multiphase/compressibleInterFoam and like dependencies to /VoF and /twoPhaseMixtureThermo to the /src directory and error persists. I'm getting a bit dispirited now... do you have any other ideas I could try? |
Hi Kevin, Just for your info. I have managed to make kva_interfaceProperties work with OFv4 on our cluster. which is reassuring.
It would be good to find out what the issue with the never versions is. Regards, Jacky Update. Differences in compilation using ./Allget && ./Allwmake scripts for OFv4 and OFv5: In both cases, the absolute path to twoPhaseMixtureThermo was manually modified. OFv4 (cluster):
OFv5 (cluster):
v5 compiles on the cluster but with some warnings:
I do not see why it should work on the cluster but not on my desktop. However, no harm in trying. |
So every single .C and .H file, including all subdirectories of the solver were copied?
That's great!
First warning is a "spacebar" on line #4 as last character, after the backslash. Remove it, and the warning disappears.
So... did it run without error?
So, had you checked whether the way Alternatively, you could start with my of40 (or of40-dev) branch. Then replace my interfaceProperties.C and interfaceProperties.H with the ones from OFv5. |
Hi Kevin, Sorry for the delay in replying.
This does not seem to solve the issue. It seems that the implementation is slightly different in v5 so I need to go through it.
I'll have a look at these algorithms. I did run some static bubble simulations in OFv4 with kva_interfaceProperites, and I can see that the parasitic currents reduce with time - which is great! However, implementing it for more advanced cases, (e.g. oscillatory pressure boundary) I am still getting unphysical behaviour at the bubble interface... which seems to indicate that there might be some numerical issues arising from this kind of boundary.
Nope! Strangely enough, now the error that crops up is the one I had quoted in my first post,
Thanks for these tips! I will try it out and let you know how I get on with this implementation. I think I have a better understanding of the implementation in v4 so it shouldn't be too difficult to get it done for v5. However, at the moment I am trying to pin point whether the issues I am experiencing are solely a result of the parasitic currents or whether there are some other issues (e.g. reflections from the domain boundaries that are causing the bubble interface to become unstable)...so it might be a while before I get this done. If it works, I am more than happy to share the changes needed for v5. Thanks again :) |
I'm sorry, I've been horribly short on time the past two weeks (and time is still scarce). How is it going? Are your previous questions still relevant at present? |
|
Hi Kevin,
Sorry to cross-post, but I've read in another post you might not check the cfd-online posts too often.
I am having some trouble in getting this to work with compressibleInterFoam in OF v5. The error is as follows:
More details on here: https://www.cfd-online.com/Forums/openfoam-verification-validation/124363-interfoam-validation-bubble-droplet-flows-microfluidics-3.html#post735107
A few other things:
Since I am using compressibleInterFoam, I manage to compile this by inserting the absolute path to twoPhaseMixtureThermo.H. I have tried implementing the changes you suggested to eliminate the reading of rho1 and rho2 from thermophysicalProperties. Unfortunately this does not seem to solve the issue, so I still have to specify the phases in thermophysicalProperties despite 'hacking' your code. It would be useful to know whether anyone else has tried it and worked, I wouldn't be surprised to find I am missing something. I did recompile and hash the solver once compilation was complete.
Also, with regards to the interfaceCompression scheme - turns out that I am also using this scheme (tbh, surprised to hear it is not really in use anymore!). How difficult is it to implement the functionality of this scheme for use with your dynamic library and compressibleInterFoam? Could you perhaps provide some guidance? I have some experience in OpenFOAM but it is my first time trying to tweak a solver, so any help is appreciated
Thanks in advance for your help on this.
Kind regards,
Jacky
The text was updated successfully, but these errors were encountered: