Incompatibility between Custom BC and ParaFoam
 

Hi all

I have made a custom boundary condition, where I need the effective viscosity (nuEff) from any given turbulence model to specify the gradient of some field at the boundary. This is working satisfactory during computations, however as nuEff is only available during the computations and I feel reluctant to write the entire field, paraFoam crashes when I am trying to load the field using that specific boundary condition, as it evaluates the boundary conditions and is unable to find nuEff.

Up to now I have tried the following:
1. try-catch in my BC (not beautiful), however it seems that OpenFOAM aborts upon reading fields, hence the try-catch was unsuccessful/overruled.
2. I have considered using the headerOk, though I have not been successful in implementing the procedure.
3. Make a script which changes zeroSedimentFlux (my BC-type) type with zeroGradient type whenever I need to visualize and vise-versa when I need to make computations. This would work, however I would like to have a more general method.

Any help is greatly appreciated.

Bests,

Niels

From your description, I assume that you have compiled your custom boundary condition as a library and have it in $FOAM_LIBBIN, which is where paraview is finding it (via the PV_PLUGIN_PATH, which is set in etc/apps/paraview3/bashrc).

If you can make sure that your custom boundary condition is NOT found by paraview, your problem should disappear. The paraview reader code should then fallback to the "generic" patch, which only needs the values on the patch but not other information.

There are several ways to keep your custom boundary condition from being found:

1. compile bc into FOAM_SITE_LIBBIN or FOAM_USER_LIBBIN.
2. compile bc directly into your solver.

Note that the FOAM_SITE_LIBBIN (and FOAM_SITE_APPBIN) scheme was added in 1.6.x for exactly that purpose: a central place for site-wide libraries and applications that is separate from the main OpenFOAM installation.

Hi Mark

Thank you very much. I took on approach (2) and compiled the boundary condition directly into the solver, as it is very solver specific anyway, and now solving, visualizing and e.g. sampling runs smoothly without any problems.

Have a nice weekend,

Niels