View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000037 | OpenFOAM | Bug | public | 2010-09-12 09:02 | 2010-10-07 18:04 |
| Reporter | Assigned To | henry | |||
| Priority | normal | Severity | major | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000037: Duplicate class Foam::alphaContactAngleFvPatchScalarField | ||||
| Description | Both, 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 Information | It would be a good idea to either rename the implementation in libmultiphaseInterFoam or put it in its own namespace. | ||||
| Tags | Modelling, Solver | ||||
|
|
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. |
|
|
> 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?). |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-09-12 09:02 |
|
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 |
|
Note Added: 0000037 | |
| 2010-09-13 05:35 |
|
Status | feedback => assigned |
| 2010-09-13 05:36 |
|
Note Edited: 0000037 | |
| 2010-09-13 07:29 |
|
Note Edited: 0000037 | |
| 2010-09-13 17:38 |
|
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 |
|
Tag Attached: Modelling |
