View Issue Details

IDProjectCategoryView StatusLast Update
0000037OpenFOAM[All Projects] Bugpublic2010-10-07 18:04
Reporteruser19Assigned Tohenry 
PrioritynormalSeveritymajorReproducibilityN/A
Status resolvedResolutionfixed 
Product Version 
Fixed in Version 
Summary0000037: Duplicate class Foam::alphaContactAngleFvPatchScalarField
DescriptionBoth, libinterfaceProperties and libmultiphaseInterFoam contain a class Foam::alphaContactAngleFvPatchScalarField. This is really bad, because if linking of multiphaseInterFoam is done in the wrong order, the linker will mix and match functions from the two implementations.

E.g. they both have a constructor with the same signature that is used in multiphaseInterFoam:

nm -A $FOAM_LIBBIN/libinterfaceProperties.so $FOAM_LIBBIN/libmultiphaseInterFoam.so | c++filt | fgrep 'alphaContactAngleFvPatchScalarField(Foam::fvPatch'
/net/eifel/mwild/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libinterfaceProperties.so:00000000000530d0 T Foam::alphaContactAngleFvPatchScalarField::alphaContactAngleFvPatchScalarField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&)
/net/eifel/mwild/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libinterfaceProperties.so:0000000000053790 T Foam::alphaContactAngleFvPatchScalarField::alphaContactAngleFvPatchScalarField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&)
/net/eifel/mwild/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libinterfaceProperties.so:00000000000530f0 T Foam::alphaContactAngleFvPatchScalarField::alphaContactAngleFvPatchScalarField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&)
/net/eifel/mwild/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libinterfaceProperties.so:0000000000053c10 T Foam::alphaContactAngleFvPatchScalarField::alphaContactAngleFvPatchScalarField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&)
/net/eifel/mwild/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libmultiphaseInterFoam.so:00000000000286a0 T Foam::alphaContactAngleFvPatchScalarField::alphaContactAngleFvPatchScalarField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&)
/net/eifel/mwild/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libmultiphaseInterFoam.so:0000000000028a70 T Foam::alphaContactAngleFvPatchScalarField::alphaContactAngleFvPatchScalarField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&)
/net/eifel/mwild/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libmultiphaseInterFoam.so:00000000000287b0 T Foam::alphaContactAngleFvPatchScalarField::alphaContactAngleFvPatchScalarField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&)
/net/eifel/mwild/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libmultiphaseInterFoam.so:0000000000028c30 T Foam::alphaContactAngleFvPatchScalarField::alphaContactAngleFvPatchScalarField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&)
Additional InformationIt would be a good idea to either rename the implementation in libmultiphaseInterFoam or put it in its own namespace.
TagsModelling, Solver

Activities

henry

2010-09-12 22:01

manager   ~0000036

Is it an issue to link the libraries in the appropriate order?

> It would be a good idea to either rename the implementation in
> libmultiphaseInterFoam

This would resolve the issue if linking the libraries in the opposite order is desired.

> or put it in its own namespace.

Because there is only one look-up table for the patch fields of a particular type this would not resolve the issue.

The alternative solution would be to split the specifically two-phase functionality out of libinterfaceProperties and into a separate library and not link it into multiphaseInterFoam.

user19

2010-09-13 05:35

  ~0000037

Last edited: 2010-09-13 07:29

View 3 revisions

> Is it an issue to link the libraries in the appropriate order?

I think linking in reverse order shouldn't create a corrupt executable... That makes for a whole lot of confusion ;-)

I ran across this while playing around with my own solver derived from multiphaseInterFoam, and just happened to name the libraries in the wrong order. It took me quite some time with GDB and squinting at the backtrace until I realised that some of the alphaContactAngleFvPatchScalarField functions were from src/transportModels/interFaceProperties while the others came from applications/solvers/multiphase/multiphaseInterFoam/multiphase.

Worst thing was, it didn't even crash properly (segfault or some such). It just behaved differently, i.e. it claimed that the keyword "limit" was undefined in the alphaair dictionary and aborted. The original solver didn't show this behaviour, so I started investigating.

>> or put it in its own namespace.

> Because there is only one look-up table for the patch fields of a particular type this would not resolve the issue.

I didn't think of the constructor tables. Scratch that...

> The alternative solution would be to split the specifically two-phase
> functionality out of libinterfaceProperties and into a separate library and
> not link it into multiphaseInterFoam.

Although it would solve the problem in this case, it still leaves the door open for undefined behaviour, especially if somebody is fooling around with the code like me.

So I'd vote for renaming. Since the implementation in libinterfaceProperties is in the public API while the one in libmultiphaseInterFoam is not strictly speaking so (that's how I understand it), I think the latter implementation should be renamed to something like multiPhaseAlphaContactAngleFvPatchScalarField (or is that misleading, since AFAIK this class still only represents the contact angle between two phases?).

henry

2010-09-13 17:42

manager   ~0000039

Resolved by commit 99f6e07575a06427c1efbabe891fda98bd70ff17 in OpenFOAM-1.7.x

The issue is resolved by the introduction of a separate library for alphaContactAngle. Renaming is not a simple solution because the interfaceProperties functions use the alphaContactAngle type directly.

An alternative strategy being considered is creating an abstract base-class for alphaContactAngle.

Issue History

Date Modified Username Field Change
2010-09-12 09:02 user19 New Issue
2010-09-12 21:55 henry Assigned To => henry
2010-09-12 21:55 henry Status new => assigned
2010-09-12 22:01 henry Note Added: 0000036
2010-09-12 22:01 henry Status assigned => feedback
2010-09-13 05:35 user19 Note Added: 0000037
2010-09-13 05:35 user19 Status feedback => assigned
2010-09-13 05:36 user19 Note Edited: 0000037 View Revisions
2010-09-13 07:29 user19 Note Edited: 0000037 View Revisions
2010-09-13 17:38 user2 Tag Attached: Solver
2010-09-13 17:42 henry Note Added: 0000039
2010-09-13 17:42 henry Status assigned => resolved
2010-09-13 17:42 henry Resolution open => fixed
2010-10-07 18:04 user2 Tag Attached: Modelling