CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Programming & Development

Adding a BC from OF V6 to OF 18.06

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   December 15, 2018, 17:41
Default Adding a BC from OF V6 to OF 18.06
  #1
New Member
 
Matt Houchin
Join Date: Mar 2017
Location: London
Posts: 11
Rep Power: 9
HouchinM is on a distinguished road
Hi Foamers,

We are currently using the CFD Support distribution of OpenFOAM v6 on our production server and would like to use the swirlFanVelocity boundary condition from OF V18.06.

Unfortunately we are not in a position to be able to move over to OF V18.06 to be able to use swirlFanVelocity, so we are adding it to the user defined boundaries.

We have compiled the swirlFanVelocity as a dynamic library with wmake (with some modifications to the .C file to make it compatible with the CFD Support distribution), however when we try to run a case (simpleFoam, K-e turbulence model) with the swirl boundary condition we get the following fatal error:

Code:
--> FOAM FATAL ERROR:
Not implemented

    From function void Foam::jumpCyclicFvPatchField<Type>::updateInterfaceMatrix(Foam::scalarField&, const scalarField&, const scalarField&, Foam::direction, Foam::UPstream::commsTypes) const [with Type = Foam::Vector<double>; Foam::scalarField = Foam::Field<double>; Foam::direction = unsigned char]
    in file /opt/OpenFOAM/OpenFOAM-dev/src/finiteVolume/lnInclude/jumpCyclicFvPatchField.C at line 141.

FOAM aborting
Is there a simple fix to the above? Or are the two distributions of OF sufficiently different such that what we are trying to do will take considerably more work?

Included are the C, H files and the make files (with a .C extension added for the file upload extension requirement)
Attached Files
File Type: c swirlFanVelocityFvPatchField.C (7.7 KB, 3 views)
File Type: h swirlFanVelocityFvPatchField.H (7.3 KB, 2 views)
File Type: c files.C (79 Bytes, 2 views)
File Type: c options.C (222 Bytes, 3 views)

Last edited by HouchinM; December 16, 2018 at 09:06. Reason: Clarified versions
HouchinM is offline   Reply With Quote

Old   December 17, 2018, 14:59
Default Possible explanation (and solution)
  #2
Member
 
Join Date: Dec 2018
Location: Darmstadt, Germany
Posts: 87
Rep Power: 7
raumpolizei is on a distinguished road
Hello there!

Allright! First post here . Lets see if I can help.

I am not too familiar with boundary conditions. What I can say from a quick code diving session is:

1. Documentation is your friend!
Your class is inheriting from fixedJumpFvPatchField<vector>. This class however is inheriting from another class: jumpCyclicFvPatchField<vector>. The function leading to the error is inside this class. If I take a look at the 18.06 class documentation (https://www.openfoam.com/documentati...8H_source.html) you can see that the function updateInterfaceMatrix has two different declarations (both are virtual, basically prescribing an interface for usage in boundary conditions derived from this class, exactly like yours). If you search a bit deeper in the .C files (where all the definitions are) you will find the definition for these functions. One of these calls the macro notImplemented. The signature of the error you are getting matches this function. This is the reason you are getting this error.

2. Is it possible to solve?
Depending on how comfortable you are with OpenFOAM (and C++, and templates), this can be done in little time ( assuming it was working in v6). Since the versions are slowly diverging, I am not 100% sure if it will work.

3. How?
From my point of view, this boundary condition is working well for scalar and vector types (why? because these are the only template specializations of this function which are not leading to the notImplemented macro. How do I know that? Have a look at the bottom of the jumpCyclicFvPatchField<vector> header (for declarations), the definitions of these "partial" specializations are in jumpCyclicFvPatchFields.C).

To wrap it up:
Try to find out for which type this error is occuring (tensorField, maybe?) then find the implementation in your working OpenFOAM v 6. Add the specialization declaration and definition to your implementation.

Wow, this got longer than expected. Hope this helps a little. All the best for your task!

RP
raumpolizei is offline   Reply With Quote

Old   December 17, 2018, 17:42
Default
  #3
New Member
 
Matt Houchin
Join Date: Mar 2017
Location: London
Posts: 11
Rep Power: 9
HouchinM is on a distinguished road
Thank you for the quick reply raumpolizei!

Based on your advice, I looked at the jumpCyclicFvPatchField header file for the 18.06 distribution and it appears that a vector definition of jumpCyclicFvPatchField<field>::updateInterfaceMatr ix is included in this header file, which is missing from the V6 distribution.

I'm assuming the trivial fix is to include the vector definition of updateInterfaceMatrix to the header file for jumpCyclicFvPatchField.

Many thanks!
HouchinM is offline   Reply With Quote

Old   December 18, 2018, 03:23
Default
  #4
Member
 
Join Date: Dec 2018
Location: Darmstadt, Germany
Posts: 87
Rep Power: 7
raumpolizei is on a distinguished road
Yep that should solve your problem. However, one point has to be corrected from my previous answer. As you mentioned, since there is no specialization for type vector in v6, the instantiated class leads directly to the notImplemented macro. I should have recognized that your class is allready inheriting from an instantiated class template with type vector. So this + the reason you mentioned is/was causing that error.
Glad I could help.
raumpolizei is offline   Reply With Quote

Old   December 18, 2018, 10:02
Default
  #5
New Member
 
Matt Houchin
Join Date: Mar 2017
Location: London
Posts: 11
Rep Power: 9
HouchinM is on a distinguished road
Thanks for the tips, I am now getting some redefinition errors.

I have followed the steps from the OpenFOAM wiki on implementing new boundary conditions. This requires me to copy the dependencies fixedJumpFvPatchField and jumpCyclicFvPatchField, rename the files and name occurrences in my run directory, include the files and new libraries in the Make folder and run wmake libso.

Unfortunately, when I compile jumpCyclicFvPatchField I am getting lots of redefinition errors:

Code:
wmake libso .
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file jumpCyclicMHFvPatchField.C
x86_64-w64-mingw32-g++ -m64 -std=c++11 -Dcygwin64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -DMSWIN -DLITTLE_ENDIAN -DMSWIN -DLITTLE_ENDIAN -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O3  -DNoRepository -ftemplate-depth-100 -I/opt/OpenFOAM/OpenFOAM-dev/src/triSurface/lnInclude -I/opt/OpenFOAM/OpenFOAM-dev/src/meshTools/lnInclude  -I/opt/OpenFOAM/OpenFOAM-dev/src/finiteVolume/lnInclude  -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-dev/src/OSspecific/MSWindows/lnInclude   -c jumpCyclicMHFvPatchField.C -o Make/cygwin64mingw-w64DPInt32Opt/jumpCyclicMHFvPatchField.o
jumpCyclicMHFvPatchField.C:31:1: error: redefinition of ‘Foam::jumpCyclicMHFvPatchField<Type>::jumpCyclicMHFvPatchField(const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&)’
 Foam::jumpCyclicMHFvPatchField<Type>::jumpCyclicMHFvPatchField
 ^
In file included from jumpCyclicMHFvPatchField.H:166:0,
                 from jumpCyclicMHFvPatchField.C:26:
jumpCyclicMHFvPatchField.C:31:1: note: ‘Foam::jumpCyclicMHFvPatchField<Type>::jumpCyclicMHFvPatchField(const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&)’ previously declared here
 Foam::jumpCyclicMHFvPatchField<Type>::jumpCyclicMHFvPatchField
 ^
jumpCyclicMHFvPatchField.C:42:1: error: redefinition of ‘Foam::jumpCyclicMHFvPatchField<Type>::jumpCyclicMHFvPatchField(const Foam::jumpCyclicMHFvPatchField<Type>&, const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&, const Foam::fvPatchFieldMapper&)’
 Foam::jumpCyclicMHFvPatchField<Type>::jumpCyclicMHFvPatchField
 ^
In file included from jumpCyclicMHFvPatchField.H:166:0,
                 from jumpCyclicMHFvPatchField.C:26:
jumpCyclicMHFvPatchField.C:42:1: note: ‘Foam::jumpCyclicMHFvPatchField<Type>::jumpCyclicMHFvPatchField(const Foam::jumpCyclicMHFvPatchField<Type>&, const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&, const Foam::fvPatchFieldMapper&)’ previously declared here
 Foam::jumpCyclicMHFvPatchField<Type>::jumpCyclicMHFvPatchField
Bearing in mind, the only thing I have changed from the original fixedJumpFvPatchField.C file is the name.

I tried asking a general C++ question about this on StackOverflow, but they sent me away saying that the template should not be defined in the C file.

jumpCyclicMHFvPatchField.C:

Code:
#include "jumpCyclicFvPatchField.H"

// * * * * * * * * * * * * * * * * Constructors  * * * * * * * * * * * * * * //

template<class Type>
Foam::jumpCyclicFvPatchField<Type>::jumpCyclicFvPatchField
(
    const fvPatch& p,
    const DimensionedField<Type, volMesh>& iF
)
:
    cyclicFvPatchField<Type>(p, iF)
{}


template<class Type>
Foam::jumpCyclicFvPatchField<Type>::jumpCyclicFvPatchField
(
    const jumpCyclicFvPatchField<Type>& ptf,
    const fvPatch& p,
    const DimensionedField<Type, volMesh>& iF,
    const fvPatchFieldMapper& mapper
)
:
    cyclicFvPatchField<Type>(ptf, p, iF, mapper)
{}


template<class Type>
Foam::jumpCyclicFvPatchField<Type>::jumpCyclicFvPatchField
(
    const fvPatch& p,
    const DimensionedField<Type, volMesh>& iF,
    const dictionary& dict
)
:
    cyclicFvPatchField<Type>(p, iF, dict)
{
    // Call this evaluation in derived classes
    // this->evaluate(Pstream::commsTypes::blocking);
}


template<class Type>
Foam::jumpCyclicFvPatchField<Type>::jumpCyclicFvPatchField
(
    const jumpCyclicFvPatchField<Type>& ptf
)
:
    cyclicFvPatchField<Type>(ptf)
{}


template<class Type>
Foam::jumpCyclicFvPatchField<Type>::jumpCyclicFvPatchField
(
    const jumpCyclicFvPatchField<Type>& ptf,
    const DimensionedField<Type, volMesh>& iF
)
:
    cyclicFvPatchField<Type>(ptf, iF)
{}


// * * * * * * * * * * * * * * * Member Functions  * * * * * * * * * * * * * //

template<class Type>
Foam::tmp<Foam::Field<Type>>
Foam::jumpCyclicFvPatchField<Type>::patchNeighbourField() const
{
    const Field<Type>& iField = this->primitiveField();
    const labelUList& nbrFaceCells =
        this->cyclicPatch().neighbFvPatch().faceCells();

    tmp<Field<Type>> tpnf(new Field<Type>(this->size()));
    Field<Type>& pnf = tpnf.ref();

    Field<Type> jf(this->jump());
    if (!this->cyclicPatch().owner())
    {
        jf *= -1.0;
    }

    if (this->doTransform())
    {
        forAll(*this, facei)
        {
            pnf[facei] = transform
            (
                this->forwardT()[0], iField[nbrFaceCells[facei]]
            ) - jf[facei];
        }
    }
    else
    {
        forAll(*this, facei)
        {
            pnf[facei] = iField[nbrFaceCells[facei]] - jf[facei];
        }
    }

    return tpnf;
}


template<class Type>
void Foam::jumpCyclicFvPatchField<Type>::updateInterfaceMatrix
(
    scalarField& result,
    const scalarField& psiInternal,
    const scalarField& coeffs,
    const direction cmpt,
    const Pstream::commsTypes
) const
{
    NotImplemented;
}


template<class Type>
void Foam::jumpCyclicFvPatchField<Type>::updateInterfaceMatrix
(
    Field<Type>& result,
    const Field<Type>& psiInternal,
    const scalarField& coeffs,
    const Pstream::commsTypes
) const
{
    Field<Type> pnf(this->size());

    const labelUList& nbrFaceCells =
        this->cyclicPatch().neighbFvPatch().faceCells();

    // only apply jump to original field
    if (&psiInternal == &this->primitiveField())
    {
        Field<Type> jf(this->jump());

        if (!this->cyclicPatch().owner())
        {
            jf *= -1.0;
        }

        forAll(*this, facei)
        {
            pnf[facei] = psiInternal[nbrFaceCells[facei]] - jf[facei];
        }
    }
    else
    {
        forAll(*this, facei)
        {
            pnf[facei] = psiInternal[nbrFaceCells[facei]];
        }
    }

    // Transform according to the transformation tensors
    this->transformCoupleField(pnf);

    // Multiply the field by coefficients and add into the result
    const labelUList& faceCells = this->cyclicPatch().faceCells();
    forAll(faceCells, elemI)
    {
        result[faceCells[elemI]] -= coeffs[elemI]*pnf[elemI];
    }
}
jumpCyclicMHFvPatchField.H

Code:
#ifndef jumpCyclicFvPatchField_H
#define jumpCyclicFvPatchField_H

#include "cyclicFvPatchField.H"

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

namespace Foam
{

/*---------------------------------------------------------------------------*\
                   Class jumpCyclicFvPatchField Declaration
\*---------------------------------------------------------------------------*/

template<class Type>
class jumpCyclicFvPatchField
:
    public cyclicFvPatchField<Type>
{

public:

    //- Runtime type information
    TypeName("jumpCyclic");


    // Constructors

        //- Construct from patch and internal field
        jumpCyclicFvPatchField
        (
            const fvPatch&,
            const DimensionedField<Type, volMesh>&
        );

        //- Construct from patch, internal field and dictionary
        jumpCyclicFvPatchField
        (
            const fvPatch&,
            const DimensionedField<Type, volMesh>&,
            const dictionary&
        );

        //- Construct by mapping given jumpCyclicFvPatchField onto a new patch
        jumpCyclicFvPatchField
        (
            const jumpCyclicFvPatchField<Type>&,
            const fvPatch&,
            const DimensionedField<Type, volMesh>&,
            const fvPatchFieldMapper&
        );

        //- Construct as copy
        jumpCyclicFvPatchField
        (
            const jumpCyclicFvPatchField<Type>&
        );

        //- Construct as copy setting internal field reference
        jumpCyclicFvPatchField
        (
            const jumpCyclicFvPatchField<Type>&,
            const DimensionedField<Type, volMesh>&
        );


    // Member functions

        // Access

            //- Return the interface type
            virtual const word& interfaceFieldType() const
            {
                return cyclicFvPatchField<Type>::type();
            }

            //- Return the "jump" across the patch as a "half" field
            virtual tmp<Field<Type>> jump() const = 0;


        // Evaluation functions

            //- Return neighbour coupled given internal cell data
            tmp<Field<Type>> patchNeighbourField() const;

            //- Update result field based on interface functionality
            virtual void updateInterfaceMatrix
            (
                scalarField& result,
                const scalarField& psiInternal,
                const scalarField& coeffs,
                const direction cmpt,
                const Pstream::commsTypes commsType
            ) const;

            //- Update result field based on interface functionality
            virtual void updateInterfaceMatrix
            (
                Field<Type>&,
                const Field<Type>&,
                const scalarField&,
                const Pstream::commsTypes commsType
            ) const;
};

//- Update result field based on interface functionality
template<>
void jumpCyclicFvPatchField<scalar>::updateInterfaceMatrix
(
    scalarField& result,
    const scalarField& psiInternal,
    const scalarField& coeffs,
    const direction cmpt,
    const Pstream::commsTypes commsType
) const;


// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

} // End namespace Foam

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

#ifdef NoRepository
    #include "jumpCyclicFvPatchField.C"
#endif

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

#endif
Why would the C file fail to compile if the only change is the name of the definition?

Many thanks for your help!
HouchinM is offline   Reply With Quote

Old   December 18, 2018, 14:29
Default
  #6
Member
 
Join Date: Dec 2018
Location: Darmstadt, Germany
Posts: 87
Rep Power: 7
raumpolizei is on a distinguished road
Hey,

don't have much time. Here is what I think:

yep, it is ok to rename the files. However, you also have to rename the class. Otherwise it is not possible to differ later between your implementation and the standard one. Should be why the compiler is complaining.
I also think you should start learning a bit of C++ and object oriented design. This will get you way faster to your goals. I was also in your position 2 years ago. It's tough at the beginning but it's worth it. Good luck!

Cheers
RP
raumpolizei is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
How I can introduce my power heat (W) in chtMultiRegionFoam? aminem OpenFOAM Pre-Processing 32 August 29, 2019 02:23
chtMultiRegionSimpleFoam: crash on parallel run student666 OpenFOAM Running, Solving & CFD 3 April 20, 2017 11:05
conjugateHeatFoam + interFoam farhagim OpenFOAM Programming & Development 15 July 19, 2016 07:55
chtMultiRegionSimpleFoam 3D problem Lucie OpenFOAM Pre-Processing 2 June 21, 2016 05:23
chtMultiRegionSimpleFoam samiam1000 OpenFOAM Running, Solving & CFD 39 March 31, 2016 08:43


All times are GMT -4. The time now is 19:19.