I can imagine that at the moment the adapter is not compatible with rhoPimpleFoam. It looks like the solver is complaining about the way we are reading heat flux:
Could you please build the adapter with debug messages enabled (see the Allwmake script and add -DADAPTER_DEBUG_MODE to the ADAPTER_PREP_FLAGS) and run again? The output will be interesting.
Thanks @Makis I did compile including the adapter as you suggested. Yeah, it’s really helpful to know what’s going on in the setting. However, I still have some doubts regarding the problem regarding this error:
in documentation, to read data for heat-flux we can only use faceCenters, and meshconnectivity is false. For this particular case i cannot use face-Nodes as it’s available for heat-flux to read data. Therefore, I tried using faceCenter location with mesh connectivity true. Adapter suggested to use that connectivity is only supported for 3D cases. but my case is 2D
So if i change dimension to 3 including z-dead=0 in RBF mapping does it computes the physically correct simulation. And also, when i do this it again shows this error
Besides the unused Solid-Mesh-nodes in the Fluid solver, the config looks fine. This also seems to be a CHT case, so I am wondering regarding the title of this thread (feel free to edit).
In the preciceDict, it looks like you have split the interface into two different ones, using the same mesh, and different locations:
I don’t know if using the same coupling mesh (Fluid-Mesh) in two different interfaces causes this issue, but it is definitely an issue. The adapter calls setMeshVertices() twice for the Fluid-Mesh, which should not even be allowed in preCICE (I need to check). The values you read should then be wrong.
Note that you don’t need the mesh connectivity, since you are using an RBF mapping. Connectivity is mainly required when you need a nearest-projection mapping - see Mapping configuration | preCICE - The Coupling Library
There seems to be some misunderstanding here. Where in the documentation did you read this?
It is definitely a cht case(typing error chat in title) for geometry similar to perpendicular flap tutorial. And for this case, I am using rhoCentralFoam rather then buoyantPimpleFoam or other heatTransfer solver available in openfoam. As per OpenFoam (OpenFOAM: User Guide: rhoCentralFoam) solver rhoCentralFoam is capable of heat transfer. And as per my necessity, i.e., observation of heatransfer between fluid and solid for cases having shockwaves. I cannot use buoyantPimpleFoam for the computation of fluid cases. With buoyantPimpleFoam for this case cht between solid and fluid was successfully observed.
At first I had set the case as per the solution you referred to. i.e.,
But error related to this term preciceAdapter::CHT::HeatFlux::read(double* buffer, const unsigned int dim) keeps presisting.
Then only after that, I tried the way with two interfaces.
at first I was using nearest-point projection therefore using mesh connectivity. And for mesh connectivity, it has the following notes:
// For cases with mesh connectivity, we support:
// - face nodes, only for writing
// - face centers, only for reading
// However, since we do not distinguish between reading and writing in the code, we
// always return true and offload the handling to the user.
Yes, I am using calculix as a solid solver which reads temperature at the nodes and heat-flux at surface as,
Further to these, I set up a case with OpenFOAM solver for both fluid (buoyantPimpleFoam) and solid (laplacianFoam) it works well. However, for the same fluid case with changes and additions of boundary conditions, I run it with rhoCentralFoam. Error preciceAdapter::CHT::HeatFlux::read(double* buffer, const unsigned int dim) persist. Just for your information, I tried adding laplacian term in the energy equation in rhocentral foam solver i.e., -fvc:laplacian(kappaEff,T)
So, my question is: To solve this issue shall I made changes to the adapter for rhoCentralFoam (I read in the thesis of Cheung it requires certain updates (its not mentioned in detail) for rhopimpleFoam). or just changes on the preciceDict and precice-config.xml file is enough.
My apologies for the confusion. If you still find it confusing regarding the issue please let me know. @Makis Thanks!
I edited the title and your last answer to mark the code snippets. You can mark inline code using backticks, like this: `This should be displayed in code font in the same line` - This should be displayed in code font in the same line. You can mark several lines to be shown as a code block, with three backticks, like this:
```c++
int main(){
std::cout << “Hello!” << std::endl;
}
```
int main(){
std::cout << "Hello!" << std::endl;
}
Where c++, you can also use xml, yaml, or just leave it empy. Please do use this feature, it makes error messages and code extremely easier to read.
Could you please try to find where in that function you get the error? You could try printing some information to the screen. You need to edit the code for that. And please upload the debug log then.
I would suggest to not look into nearest-projection and mesh connectivity yet. You could use it to optimize an already well-running case, but it is more complicated.
