[deepsterblue]

Umm... You would need to download and install OpenFOAM-1.6-ext first.

Clone the repository:

git clone ssh://username@openfoam-extend.git.sourceforge.net/gitroot/openfoam-extend/OpenFOAM-1.6-ext

Installation instructions are here:

http://openfoam-extend.git.sourcefor...a69f5e;hb=HEAD

[SMesser]

Thanks for the link.

I was able to download the package, but there isn't much in the way of executable binaries that seem to come with it. Trying the AllMake scripts from the ThirdParty directory, but it's slow going. The default value for WM_THIRD_PARTY_DIR points to the wrong directory, and the values in the README files also seem to be inconsistent with the install. After downloading & installing some additional packages (via YaST), I can get AllMake.stage0 - 2 to run without incident. AllMake.Stage3 may or may not be failing; I get this:

RPM build errors:
Installing package: ParMetis-3.1.1
  Uninstalling ParMetis-3.1.1 using RPM: ParMetis-3.1.1-linuxGccDPOpt.i586
  Installing ParMetis-3.1.1 using RPM file: /opt/openfoam171/ThirdParty/rpmBuild/RPMS/i586/ParMetis-3.1.1-linuxGccDPOpt.i586.rpm
Done installing package ParMetis-3.1.1

I don't know if that means "no error", that the installation of ParMetis was a mistake, or that re-installation of ParMetis was done as damage control. In any case, I get a similar possible-error with scotch-5.1.10b and icoDyMFoam doesn't seem to be available as a command afterwards. Running "find -name icoDyMFoam" from /opt/openfoam171 doesn't turn up any binaries, although several other binary executables have been added to /opt/openfoam171/applications/bin/linuxGccDPOpt and I do see the icoDyMFoam directory under /opt/openfoam171/applications/solvers/incompressible/

I don't know if this is related to earlier troubles with OpenFoam - I've tried recompiling the code twice earlier, but it destroys its own binaries and spits out lots of errors. It's possible that my messing with /opt/openfoam171/etc/bashrc to re-point WM_THIRD_PARTY_DIR *might* have fixed that too...

I'll poke around and see what else I can find.

Any advice you can give me would be great. Thank you

[deepsterblue]

It looks like you're messing up different Foam installations. It might help to unset the WM_THIRD_PARTY_DIR in your .bashrc, and do a foamInstallationTest to ensure that everything's okay.

[deepsterblue]

Oh... I think I get it. Are you sourcing your 1.6-ext bashrc? Make sure you have a line like this in ~/.bashrc

# Source the OpenFOAM-1.6-ext installation
. ~/OpenFOAM/OpenFOAM-1.6-ext/etc/bashrc

... and do a foamInstallationTest to make sure it's okay. You appear to be using a central OpenFOAM-1.7.1 installation through YaST, where the ThirdParty directory is located differently.

[SMesser]

If I put "unset WM_THIRD_PARTY_DIR" at the end of my ~/.bashrc and source the file, foamInstallationTest gives me this:

Executing /opt/openfoam171/bin/foamInstallationTest:


Checking basic setup...
-------------------------------------------------------------------------------

FATAL ERROR: OpenFOAM environment not configured.

    Please refer to the installation section of the README file:
    <OpenFOAM installation dir>/OpenFOAM-1.7.x/README
    to source the OpenFOAM environment.

If I leave WM_THIRD_PARTY_DIR in place as I've modified it, I get this:

Executing /opt/openfoam171/bin/foamInstallationTest:


Checking basic setup...
-------------------------------------------------------------------------------
Shell:              bash
Host:               johnny5
OS:                 Linux version 2.6.34.8-0.2-desktop
-------------------------------------------------------------------------------


Checking main OpenFOAM env variables...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid      Crit
-------------------------------------------------------------------------------
$WM_PROJECT_INST_DIR /opt                                     yes       yes
$WM_PROJECT_USER_DIR /home/sarah/OpenFOAM/sarah-1.7.1         yes       no
$WM_THIRD_PARTY_DIR  /opt/openfoam171/ThirdParty              yes       yes
-------------------------------------------------------------------------------


Checking the OpenFOAM env variables set on the PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid Path Crit
-------------------------------------------------------------------------------
$WM_PROJECT_DIR      /opt/openfoam171                         yes  yes  yes

$FOAM_APPBIN         ...am171/applications/bin/linuxGccDPOpt  yes  yes  yes
$FOAM_SITE_APPBIN    /opt/site/1.7.1/bin/linuxGccDPOpt        no        no
$FOAM_USER_APPBIN    ...1.7.1/applications/bin/linuxGccDPOpt  no        no
$WM_DIR              /opt/openfoam171/wmake                   yes  yes  yes
-------------------------------------------------------------------------------


Checking the OpenFOAM env variables set on the LD_LIBRARY_PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid Path Crit
-------------------------------------------------------------------------------
$FOAM_LIBBIN         /opt/openfoam171/lib/linuxGccDPOpt       yes  yes  yes
$FOAM_SITE_LIBBIN    /opt/site/1.7.1/lib/linuxGccDPOpt        no        no
$FOAM_USER_LIBBIN    ...enFOAM/sarah-1.7.1/lib/linuxGccDPOpt  no        no
$MPI_ARCH_PATH       --------- env variable not set ---------            yes
-------------------------------------------------------------------------------


Third party software
-------------------------------------------------------------------------------
Software Version   Location 
-------------------------------------------------------------------------------
gcc      4.5.0     /usr/bin/gcc                                             
gzip     1.3.13    /usr/bin/gzip                                            
tar      1.23      /bin/tar                                                 
icoFoam  1.7.x     /opt/openfoam171/applications/bin/linuxGccDPOpt/icoFoam  
-------------------------------------------------------------------------------


Summary
-------------------------------------------------------------------------------
Base configuration ok.

Critical systems ok.

done.

This seems to say it's fine in the summary, but higher up, it says there are several invalid directories and missing variables. I'll see what I can do about tracking down & fixing those.

What do you mean by

It looks like you're messing up different Foam installations.

?

Is OpenFOAM-1.6-ext incompatible with OpenFoam 1.7.1? Should I go looking for OpenFoam 1.6?

Thanks

[deepsterblue]

OF-1.6-ext and OF-1.7.1 can coexist without problems. All you need to do is make sure that the relevant bashrc is being sourced correctly. Here's a sample of mine:

# Source the OpenFOAM-1.5-dev installation
#. ~/OpenFOAM/OpenFOAM-1.5-dev/etc/bashrc

# Source the OpenFOAM-1.6-ext installation
. ~/OpenFOAM/OpenFOAM-1.6-ext/etc/bashrc

# Source the OpenFOAM-1.7.x installation
#. ~/OpenFOAM/OpenFOAM-1.7.x/etc/bashrc

As you can see, I just comment/un-comment the relevant version as necessary.

[SMesser]

Okay, that makes sense now - I'd been treating OpenFOAM-1.6-ext as just a bunch of add-ons, but it looks like it makes more sense to treat it as a standalone package....
so it's now in /opt/openfoam16x/OpenFOAM-1.6-ext/
I was trying to mimic the directory structure for openfoam171, but it looks like that got messed up somehow. I've tweaked foamInstall in the etc/bashrc, though, so hopefully that's fine.

./Allwmake from the OpenFOAM-1.6-ext directory gives a number of "No such file or directory" errors related to specific header files: mpi.h, and decompositionMethod.H, which are apparently needed by OPwrite.C, IPread.C, scotchDecomp.H, metisDecomp.H, and parMetisDecomp.H

I've three different mpi.h on my system, under:
paraviewopenfoam381
linux-2.6.34.8.0.2
linux-2.6.34.8-0.2-obj

There are five different OPwrite.C and seven different IPread.C; is there a way to make the error more specific? Is there a way to tell which environment variable needs to be twiddled to make it go?

Thank you once again.

[SMesser]

So tried that "foamInstallationTest" you mentioned before (should've done it before I posted, but the "Submit Reply" button's tempting... and I want to log my error path too...):

Checking basic setup...
-------------------------------------------------------------------------------
Shell:              bash
Host:               johnny5
OS:                 Linux version 2.6.34.8-0.2-desktop
-------------------------------------------------------------------------------


Checking main OpenFOAM env variables...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid      Crit
-------------------------------------------------------------------------------
$WM_PROJECT_INST_DIR /opt/openfoam16x                         yes       yes
$WM_PROJECT_USER_DIR /home/sarah/OpenFOAM/sarah-1.6-ext       no        no
$WM_THIRD_PARTY_DIR  ...nfoam16x/OpenFOAM-1.6-ext/ThirdParty  yes       yes
-------------------------------------------------------------------------------


Checking the OpenFOAM env variables set on the PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid Path Crit
-------------------------------------------------------------------------------
$WM_PROJECT_DIR      /opt/openfoam16x/OpenFOAM-1.6-ext        yes  yes  yes

$FOAM_APPBIN         ...6-ext/applications/bin/linuxGccDPOpt  no        yes
$FOAM_SITE_APPBIN    ...am16x/site/1.6-ext/bin/linuxGccDPOpt  no        no
$FOAM_USER_APPBIN    ...6-ext/applications/bin/linuxGccDPOpt  no        no
$WM_DIR              /opt/openfoam16x/OpenFOAM-1.6-ext/wmake  yes  yes  yes
-------------------------------------------------------------------------------


Checking the OpenFOAM env variables set on the LD_LIBRARY_PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid Path Crit
-------------------------------------------------------------------------------
$FOAM_LIBBIN         ...x/OpenFOAM-1.6-ext/lib/linuxGccDPOpt  yes  yes  yes
$FOAM_SITE_LIBBIN    ...am16x/site/1.6-ext/lib/linuxGccDPOpt  no        no
$FOAM_USER_LIBBIN    ...FOAM/sarah-1.6-ext/lib/linuxGccDPOpt  no        no
$MPI_ARCH_PATH       --------- env variable not set ---------            yes
-------------------------------------------------------------------------------


Third party software
-------------------------------------------------------------------------------
Software Version   Location 
-------------------------------------------------------------------------------
WARNING: gcc version does not match gcc supplied with this release of OpenFOAM
         Supplied version: 4.3.3
         User version    : 4.5.0
         Minimum required: 4.3.1

gcc      4.5.0    
WARNING:  Conflicting installations:
          OpenFOAM settings        : /bin/gcc
          current path             : /usr/bin/gcc
          CRITICAL ERROR

gzip     1.3.13    /usr/bin/gzip                                            
tar      1.23      /bin/tar                                                 
icoFoam           
WARNING:  Conflicting installations:
          OpenFOAM settings        : /opt/openfoam16x/OpenFOAM-1.6-ext/applications/bin/linuxGccDPOpt/icoFoam
          current path             : 
          CRITICAL ERROR

-------------------------------------------------------------------------------


Summary
-------------------------------------------------------------------------------
Base configuration ok.

The foam installation contains 2 critical error(s).

Review the output for warning messages and consult 
the installation guide for trouble shooting.

done.

going to poke at this a bit, but I'm still trying to figure out what files to edit....

*sigh*

[deepsterblue]

Almost there, but not quite. Again, you shouldn't have to edit files anywhere to get this to work - a single line in your .bashrc should suffice.

I see you've opted for a central install - this is fine (although I personally wouldn't use this approach), but you probably want to be root before building things, if you do it this way.

Make sure that the ThirdParty directory has been built before an Allwmake in the OpenFOAM-1.6-ext directory (easy enough to do - an Allmake in the $WM_THIRD_PARTY_DIR will get you going). The ThirdParty directory contains sources to MPI, metis, scotch, etc., so your problems should go away once that is done.

This thread appears to have become hijacked for installation, when it should've been addressing 'sonicDyMFoam', and that's rather unfortunate. Remember, the forum search function is your friend.

[SMesser]

Sorry about the threadjack. It wasn't intentional. I've continued describing my attempts to install OpenFOAM-1.6-ext here.

[SMesser]

I tried adapting the movingConeTopo case from OpenFoam-1.6-ext to use the sonicDyMFoam solver instead of the icoDyMFoam, but ran into trouble:
1) sonicDyMFoam doesn't exist under 1.6-ext (I've a compressible fluid traveling at transonic velocities, so icoDyMFoam used in the movingConeTopo case won't work.)
2) 1.7.1 sonicDyMFoam and 1.6-ext icoDyMFoam apparently set up the dynamicMeshDict differently. (e.g. 1.6-ext icoDyMFoam doesn't have a pointMotionUx field or the "solver" keyword, both of which are apparently required for 1.7.1 sonicDyMFoam)

I've tried a couple different ways to set it up, but I either get crashiness or a mesh which apparently splits into two overlapping, inconsistent grids after the first time step. (After splitting the mesh, sonicDyMFoam continues to run for a while, but eventually things get so strained that it crashes.)

The meat of my dynamicMeshDict is:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
//    object      motionProperties;
    object      dynamicMeshDict;        //SJM-2011-05-26
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

//dynamicFvMesh      dynamicMotionSolverFvMesh;
//dynamicFvMeshLibs     1("libtopoChangerFvMesh.so")    //SJM-2011-05-25
dynamicFvMesh   movingConeTopoFvMesh;

movingConeTopoFvMeshCoeffs
{
        motionVelAmplitude      (-200 0 0);
        motionVelPeriod         1e-5;

        leftEdge        -0.003;
        leftObstacleEdge        -0.0028;
        rightObstacleEdge       -0.0002;

        left
        {
                minThickness    2e-4;
                maxThickness    5e-4;
        }

        right
        {
                minThickness    2e-4;
                maxThickness    5e-4;
        }
}

motionSolverLibs ("libfvMotionSolvers.so");

solver              velocityComponentLaplacian x;

diffusivity         directional ( 1 200 0 );

I figure the mesh-splitting trouble comes about because there are two different algorithms trying to modify the mesh... but I'm not sure what to do about that.

I tried looking at some of the source code in $FOAM_SRC/dynamicFvMesh/solidBodyMotionFvMesh/solidBodyMotionFunctions
but 1) I'm not sure if that's applicable to me, and 2) although I can see a few things that look familiar, I don't see the requirements for pointMotionUx in this or any of the other code under $FOAM_SRC/dynamcFvMesh

Can I get a pointer to something relevant? Maybe a help file? or a tutorial?

You know, "Baby's first sonicDyMFoam case"?

Thanks.

[deepsterblue]

Hmm... It does look like sonicDyMFoam doesn't exist on 1.6-ext. But the solver should be compatible - copy it over to your 1.6-ext installation from 1.7.x, compile it and see.

It would help to see some pictures of what your problem is, and a log file of the run, if that helps.

[SMesser]

Okay,

so the problems I reported before got resolved by rebooting my machine. I'd tried unsetting $FOAM_INST_DIR and re-sourcing my (revised for 1.6-ext) .bashrc, but that seems to be incomplete: there are some state variables somewhere which were still pointing to 1.6-ext, while others pointed to 1.7.1

Once I rebooted, I was able to run sonicDyMFoam under OpenFOAM 1.7.1, but instead of the libtopoChangerFvMesh effect of moving grid cells from one side of the poppet to the other as the poppet moved, I instead got the dynamicMotionSolverFvMesh effect of constant # of grid cells stretching as the poppet moves. (To recap, this causes trouble because the cells on one side get squeezed down to a huge aspect ratio while those on the other side stretch to horrid resolution.)

I'm attaching a couple pix of the mesh from the 1.7.1 run to show how it changed. (Yes, my initial mesh is lopsided, but I figured I'd deal with that after I sorted out the not-running issues.)

So after that, I tried your suggestion of copying everything (my "valve" case and the sonicDyMFoam source) over to 1.6-ext, this time making sure to edit the .bashrc and do a full reboot before fiddling with anything important. I tried running Allwmake from the OpenFoam-1.6-ext directory, but ran into some "motionSolver.H" not found errors. So I compared the directory structures on each side, and found that motionSolver.H shows up in four places under OpenFOAM 1.7.1:

src/dynamicMesh/motionSolver
src/dynamicMesh/lnInclude
src/dynamicMesh/dynamicMesh/motionSolver
src/dynamicMesh/dynamicMesh/lnInclude

Only the last two of these were under 1.6-ext, so I copied these two existing 1.6-ext directories upwards a level to mimic the 1.7.1 hierarchy. This allowed Allwmake to run without errors.

Then I switched back to the "run/valve/constant" directory and tried editting dynamicMeshDict to be close to the original plan for the "movingConeTopo" case...

Apparently 1.6-ext dislikes the "inletOutlet" boundary conditions I was using under 1.7.1, so I closed off the boundaries, basically making the inletOutlet faces look like hard walls. (Not real happy about that, but at least it'll let me address the meshing issues until I figure out how 1.6-ext handles open boundaries.)

Along the way, I found that under 1.6-ext, I need to run "cp -r 0.org 0" between the ./Allclean and ./Allrun scripts.

After that, I found that sonicDyMFoam complains that I haven't put the "solver" keyword in constant/dynamicMeshDict, despite the fact that it wasn't in the original icoDyMFoam example I've been using as a model:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object        dynamicMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dynamicFvMeshLibs   1("libtopoChangerFvMesh.so")

dynamicFvMesh        movingConeTopoFvMesh;

movingConeTopoFvMeshCoeffs
{
        motionVelAmplitude      (-200 0 0);
        motionVelPeriod         1e-5;

        leftEdge        -0.003;
        leftObstacleEdge        -0.0028;
        rightObstacleEdge       -0.0002;

        left
        {
                minThickness    2e-4;
                maxThickness    5e-4;
        }

        right
        {
                minThickness    2e-4;
                maxThickness    5e-4;
        }
}

yields

--> FOAM FATAL IO ERROR: 
keyword solver is undefined in dictionary "/home/sarah/OpenFOAM/sarah-1.6-ext/run/valve/constant/dynamicMeshDict"

file: /home/sarah/OpenFOAM/sarah-1.6-ext/run/valve/constant/dynamicMeshDict from line 17 to line 39.

    From function dictionary::lookupEntry(const word&, bool, bool) const
    in file db/dictionary/dictionary.C at line 396.
FOAM exiting

If I try running the hybridized dynamicMeshDict I built under 1.7.1, I get something about an empty solver table:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      motionProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dynamicFvMesh      dynamicMotionSolverFvMesh;

motionSolverLibs ("libfvMotionSolvers.so");

solver              velocityComponentLaplacian x;

diffusivity         directional ( 1 200 0 );

yields

Selecting motion solver: velocityComponentLaplacian
--> FOAM Warning : 
    From function dlLibraryTable::open(const fileName& functionLibName)
    in file db/dlLibraryTable/dlLibraryTable.C at line 86
    could not load libfvMotionSolvers.so: cannot open shared object file: No such file or directory


--> FOAM FATAL ERROR: 
solver table is empty

    From function motionSolver::New(const polyMesh& mesh)
    in file motionSolver/motionSolver.C at line 95.

Erm. Thanks for the help, but I'm not sure what to do next. Are there other solvers which look appropriate?

[deepsterblue]

The dynamicMesh directory structure is different from OF-1.7.x, so it's not surprising that sonicDyMFoam doesn't compile.

Originally Posted by SMesser

Only the last two of these were under 1.6-ext, so I copied these two existing 1.6-ext directories upwards a level to mimic the 1.7.1 hierarchy. This allowed Allwmake to run without errors.

This is the problem. You can't move the sources around like this. Rather, modify the Make/options in the sonicDyMFoam directory to point to the appropriate location in 1.6-ext.

Also, looking at the sonicDyMFoam sources, it's geared for mesh-motion alone, and not topo-changes. You'll have to re-write a bit if you're planning on introducing layering (i.e., using the topoChangerFvMesh stuff).

I would also look into the tetDecompositionMotionSolvers / mesquiteMotionSolver for mesh-motion, which may alleviate some of your issues.

[SMesser]

just to make sure I understand... you're recommending that I edit sonicDyMFoam.C so that it runs with topoChangerFvMesh.C instead of velocityComponentLaplacianFvMotionSolver.C, which I think I've used above (or else, tetDecompositionMotionSolver.C or mesquiteMotionSolver.C might be more useful)? Do you have anything which compares the three dynamicMesh solvers? Without knowing what features / types of mesh motion are available in each, it's a bit hard to choose between them.

I took a glance at each of the source files mentioned above, and while I got some quick impressions of what was going on, what I'm supposed to do didn't leap out at me. (That may be because it's been more than a decade since I did serious C coding and that was mostly C, with only a bit of C++, and on a much smaller scale than OpenFOAM.)

If I understand you right, I should only need to edit sonicDyMFoam.C, and only the parts that deal with meshing? Will I need to copy over the fields to the new grid manually, or do the dynamicMesh solvers handle that for me? What about the changes to the vector fields and vector operators? I'm hoping that the dynamicMesh solvers will handle all that if I just call the appropriate functions....

Do you have links for documentation on them? Or maybe sample code with & without changes similar to those I'll need to make?

Forgive me if I'm skittish or seem a bit dull. I haven't edited OpenFOAM source before, and there's clearly a lot of data-hiding and operator-overloading going on... and the in-file documentation is aimed at folks who're familiar with the code.

Thanks again for your help.

[deepsterblue]

just to make sure I understand... you're recommending that I edit sonicDyMFoam.C so that it runs with topoChangerFvMesh.C instead of velocityComponentLaplacianFvMotionSolver.C, which I think I've used above (or else, tetDecompositionMotionSolver.C or mesquiteMotionSolver.C might be more useful)?

Correct. All three solvers are derived from the motionSolver class, which only moves mesh points, but does not introduce or remove points from the mesh (i.e., changes to mesh topology).

Do you have anything which compares the three dynamicMesh solvers? Without knowing what features / types of mesh motion are available in each, it's a bit hard to choose between them.

They're all mesh-motion solvers. I can't comment on which one's better, since they all have their fair share of advantages and disadvantages. But then again, it's easy to switch between them at any point.

If I understand you right, I should only need to edit sonicDyMFoam.C, and only the parts that deal with meshing?

Correct.

Will I need to copy over the fields to the new grid manually, or do the dynamicMesh solvers handle that for me?

Nope. You shouldn't have to do anything. The mesh class is supposed to do all that for you automatically.

What about the changes to the vector fields and vector operators? I'm hoping that the dynamicMesh solvers will handle all that if I just call the appropriate functions....

All done automatically. If you use a dynamicFvMesh / topoChangerFvMesh class, the mesh.update() function should handle it for you.

Do you have links for documentation on them? Or maybe sample code with & without changes similar to those I'll need to make?

That's a little hard to find, but take a look at various dynamic mesh solvers (which use the DyM addition to conventional ones), and available tutorials. Searching online in general should help too.

[SMesser]

Was missing several libraries during compilation... I'm not sure if I'm doing right by dropping some of them; I'm trying to redirect them in those cases where I can find appropriate things - but several of the .H files appear to be very application-specific.

I'm also having trouble getting this to compile. The current resistant error is

sonicDyMFoam.C:(.text+0x1ddb): undefined reference to `Foam::dynamicFvMesh::New(Foam::IOobject const&)'

which, I'm afraid, doesn't mean much to me.

I'd hoped the 0x1ddb was a byte offset in the source file, but the file's not that long.... I mean, I'm pretty sure the error has to do with a call to the New() method of the dynamicFvMesh class, which subclasses Foam, but... I don't know where the code calls that or how to address it. (Include additional libraries? drop a couple lines? write something from scratch?)

Here's the current state of my code:

#include "fvCFD.H"
#include "basicPsiThermo.H"
#include "turbulenceModel.H"
#include "motionSolver.H" 
#include "dynamicFvMesh.H"  

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

int main(int argc, char *argv[])
{
    #include "setRootCase.H"
    #include "createTime.H"
    //#include "createMesh.H"   
    #include "createDynamicFvMesh.H"    
    #include "initContinuityErrs.H"
    #include "initTotalVolume.H"    
    #include "createFields.H"

    autoPtr<Foam::motionSolver> motionPtr = motionSolver::New(mesh);  

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

    Info<< "\nStarting time loop\n" << endl;

    //while (runTime.loop())    
    while (runTime.run())   
    {
        //#include "readControls.H"   
        #include "checkTotalVolume.H"   
        #include "compressibleCourantNo.H"  
        //#include "setDeltaT.H"  
        
        //Make the fluxes absolute  
        fvc::makeAbsolute(phi,U);   
        
        runTime++;
        
        Info<< "Time = " << runTime.timeName() << nl << endl;

        bool meshChanged = mesh.update();  
        
        #include "readPISOControls.H"     
        //#include "compressibleCourantNo.H"    
        
        #include "volContinuity.H"  

        //mesh.movePoints(motionPtr->newPoints());  

        //if (correctPhi && meshChanged)  
        //{   
            //Fluxes will be corrected to absolute velocity 
            //#include "correctPhi.H" 
        //}   
        
        //Make the fluxes relative to the mesh motion   
        fvc::makeRelative(phi,U);   
        
        if (meshChanged)    
        {   
            #include "compressibleCourantNo.H"  
        }       
        
        #include "rhoEqn.H"

        fvVectorMatrix UEqn
        (
            fvm::ddt(rho, U)
          + fvm::div(phi, U)
          + turbulence->divDevRhoReff(U)
        );

        solve(UEqn == -fvc::grad(p));

        #include "eEqn.H"


        // --- PISO loop

        for (int corr=0; corr<nCorr; corr++)
        {
            U = UEqn.H()/UEqn.A();

            surfaceScalarField phid
            (
                "phid",
                fvc::interpolate(psi)
               *(
                    (fvc::interpolate(U) & mesh.Sf()) - fvc::meshPhi(rho, U)
                )
            );

            for (int nonOrth=0; nonOrth<=nNonOrthCorr; nonOrth++)
            {
                fvScalarMatrix pEqn
                (
                    fvm::ddt(psi, p)
                  + fvm::div(phid, p)
                  - fvm::laplacian(rho/UEqn.A(), p)
                );

                //pEqn.solve(); 
                if (corr == nCorr - 1 && nonOrth == nNonOrthCorr)   
                {   
                    pEqn.solve(mesh.solver(p.name() + "Final"));    
                }   
                else    
                {   
                    pEqn.solve(mesh.solver(p.name()));  
                }   

                phi = pEqn.flux();
            }

            #include "compressibleContinuityErrs.H"

            // Make the fluxes relative to the mesh motion  
            fvc::makeRelative(phi,U);   

            U -= fvc::grad(p)/UEqn.A();
            U.correctBoundaryConditions();
        }

        DpDt = fvc::DDt
        (
            surfaceScalarField
            (
                "phiU",
                phi/fvc::interpolate(rho) + fvc::meshPhi(rho, U)
            ),
            p
        );

        turbulence->correct();

        rho = psi*p;

        runTime.write();

        Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s"
            << "  ClockTime = " << runTime.elapsedClockTime() << " s"
            << nl << endl;
    }

    Info<< "End\n" << endl;

    return 0;
}

Insight is appreciated, as always

[deepsterblue]

Linker issue. You're probably missing an -ldynamicFvMesh in your Make/options file.

[SMesser]

Okay, the -ldynamicFvMesh got sonicDyMFoam to compile, but trouble results when it runs because the (custom) dynamicFvMesh, "puffValveTopoFvMesh" isn't being recognized. I described the results in some detail here. I think the main question I have now is "How do I get the OpenFOAM suite to recognize I've added a new dynamicFvMesh. (I suppose I can replace / edit one of the existing utilities, but that seems like an inappropriate solution.)

Thank you

[SMesser]

That's now fixed, but I'm running into a dimensions error when I try to run my modded sonicDyMFoam:

Different dimensions for -=
     dimensions : [1 0 -1 0 0 0 0] = [0 3 -1 0 0 0 0]

which looks like I lost / gained a factor of density somewhere in the code-copying. That seems like an odd result to me, so I tried working with the various #include statements. I had commented out a few of them because of undeclared-variable errors. This apparently arises at the line "fvc::makeRelative(phi,U);" in the code below.

(Note to fellow n00Bs: Many of OpenFOAM's *.H files contain code, not just prototypes, macros, and compiler directives. That's a big change from the "C 101" courses I took nearly twenty years ago...)

Anyhow, I put the includes back, which required me to track down definitions that happen in different files for different solvers. The end result is mostly the original sonicDyMFoam.C, but mixes in bits from compressibleInterDyMFoam.C and icoDyMFoam.C. Here's the code:

/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     |
    \\  /    A nd           | Copyright (C) 1991-2010 OpenCFD Ltd.
     \\/     M anipulation  |
-------------------------------------------------------------------------------
License
    This file is part of OpenFOAM.

    OpenFOAM is free software: you can redistribute it and/or modify it
    under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    OpenFOAM is distributed in the hope that it will be useful, but WITHOUT
    ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
    FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
    for more details.

    You should have received a copy of the GNU General Public License
    along with OpenFOAM.  If not, see <http://www.gnu.org/licenses/>.

Application
    sonicDyMFoam

Description
    Transient solver for trans-sonic/supersonic, laminar or turbulent flow
    of a compressible gas with dynamic mesh.

Modifications by Sarah Messer to allow topological mesh changes, with 
    many thanks to Sandeep Menon for patient guidance
\*---------------------------------------------------------------------------*/

#include "fvCFD.H"
#include "basicPsiThermo.H"
#include "turbulenceModel.H"
#include "motionSolver.H" 
#include "dynamicFvMesh.H"

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

int main(int argc, char *argv[])
{
    #include "setRootCase.H"
    #include "createTime.H"
    #include "createDynamicFvMesh.H"
    #include "createFields.H"
    #include "initContinuityErrs.H"
    #include "initTotalVolume.H"

    //autoPtr<Foam::motionSolver> motionPtr = motionSolver::New(mesh);

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

    Info<< "\nStarting time loop\n" << endl;

    while (runTime.run())
    {
        #include "readControls.H"
        #include "checkTotalVolume.H"
        #include "compressibleCourantNo.H"
        #include "volContinuity.H"

        //Make the fluxes absolute
        fvc::makeAbsolute(phi,U);

        #include "setDeltaT.H"

        runTime++;
        
        Info<< "Time = " << runTime.timeName() << nl << endl;

        // Store divU from the previous mesh for the correctPhi
            volScalarField divU = fvc::div(phi);

        bool meshChanged = mesh.update();
        
        if (correctPhi && meshChanged)
        {
            //Fluxes will be corrected to absolute velocity
            #include "correctPhi.H"
        }

        Info << "SJM: makeRelative(phi,U)" << nl << endl;

        //Make the fluxes relative to the mesh motion
        fvc::makeRelative(phi,U);
        
        if (meshChanged)
        {
            #include "compressibleCourantNo.H"
        }
        Info << "SJM: include rhoEqn.H" << nl << endl;
        
        #include "rhoEqn.H"
        
        Info << "SJM: UEqn setup" << nl << endl;
        
        fvVectorMatrix UEqn
        (
            fvm::ddt(rho, U)
          + fvm::div(phi, U)
          + turbulence->divDevRhoReff(U)
        );

        Info << "SJM: UEqn solve" << nl << endl;
        
        solve(UEqn == -fvc::grad(p));

        #include "eEqn.H"


        // --- PISO loop
        Info << "SJM: PISO loop" << nl << endl;       

        for (int corr=0; corr<nCorr; corr++)
        {
            U = UEqn.H()/UEqn.A();

            surfaceScalarField phid
            (
                "phid",
                fvc::interpolate(psi)
               *(
                    (fvc::interpolate(U) & mesh.Sf()) - fvc::meshPhi(rho, U)
                )
            );

            for (int nonOrth=0; nonOrth<=nNonOrthCorr; nonOrth++)
            {
                fvScalarMatrix pEqn
                (
                    fvm::ddt(psi, p)
                  + fvm::div(phid, p)
                  - fvm::laplacian(rho/UEqn.A(), p)
                );

                //pEqn.solve(); 
                if (corr == nCorr - 1 && nonOrth == nNonOrthCorr)   
                {   
                    pEqn.solve(mesh.solver(p.name() + "Final"));    
                }   
                else    
                {   
                    pEqn.solve(mesh.solver(p.name()));  
                }   

                phi = pEqn.flux();
            }

            #include "compressibleContinuityErrs.H"

            // Make the fluxes relative to the mesh motion  
            fvc::makeRelative(phi,U);   

            U -= fvc::grad(p)/UEqn.A();
            U.correctBoundaryConditions();
        }

        Info << "SJM: DpDt setup" << nl << endl;    

        DpDt = fvc::DDt
        (
            surfaceScalarField
            (
                "phiU",
                phi/fvc::interpolate(rho) + fvc::meshPhi(rho, U)
            ),
            p
        );

        turbulence->correct();

        rho = psi*p;

        runTime.write();

        Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s"
            << "  ClockTime = " << runTime.elapsedClockTime() << " s"
            << nl << endl;
    }

    Info<< "End\n" << endl;

    return 0;
}


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

To make this compile, I also had to create / revise three files in the sonicDyMFoam directory. These are

readControls.H (copied from icoDyMFoam.H)
correctPhi.H (copied from compressibleInterDyMFoam.H)
and
createFields.H:

    Info<< "Reading thermophysical properties\n" << endl;

    autoPtr<basicPsiThermo> pThermo
    (
        basicPsiThermo::New(mesh)
    );
    basicPsiThermo& thermo = pThermo();

    volScalarField& p = thermo.p();
    volScalarField& e = thermo.e();
    const volScalarField& psi = thermo.psi();

    volScalarField rho
    (
        IOobject
        (
            "rho",
            runTime.timeName(),
            mesh
        ),
        thermo.rho()
    );

    Info<< "Reading field U\n" << endl;
    volVectorField U
    (
        IOobject
        (
            "U",
            runTime.timeName(),
            mesh,
            IOobject::MUST_READ,
            IOobject::AUTO_WRITE
        ),
        mesh
    );

#   include "compressibleCreatePhi.H"


    Info<< "Creating turbulence model\n" << endl;
    autoPtr<compressible::turbulenceModel> turbulence
    (
        compressible::turbulenceModel::New
        (
            rho,
            U,
            phi,
            thermo
        )
    );

    Info<< "Creating field DpDt\n" << endl;
    volScalarField DpDt =
        fvc::DDt(surfaceScalarField("phiU", phi/fvc::interpolate(rho)), p);

    wordList pcorrTypes
    (
        p.boundaryField().size(),
        zeroGradientFvPatchScalarField::typeName
    );

    for (label i=0; i<p.boundaryField().size(); i++)
    {
        if (p.boundaryField()[i].fixesValue())
        {
            pcorrTypes[i] = fixedValueFvPatchScalarField::typeName;
        }
    }

This doesn't change the dimensions error cited above, but I think I've done the right thing by working in these libraries. I guess the next question is: Are there dimensions changes between sonicDyMFoam.C and the icoDyMFoam.C I've used for the topological changes? maybe a volumetric flow rate gets replaced with a mass flow rate somewhere?

Thanks once again for the help