sonicDyMFoam
 

Hi everybody,

I am trying to set up a case in OpenFOAM 1.6.x and run it using sonicDyMFoam, but I can't get past the thermophysicalProperties. when I run the solver it gives me the following error:

Selecting thermodynamics package hPsiThermo<pureMixture<constTransport<specieThermo <hConstThermo<perfectGas>>>>>


--> FOAM FATAL ERROR:
Not implemented

From function basicThermo::e()
in file basicThermo/basicThermo.C at line 355.

FOAM aborting

#0 Foam::error::printStack(Foam::Ostream&) in "/opt/software/openfoam/public/OpenFOAM/Git/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/opt/software/openfoam/public/OpenFOAM/Git/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 Foam::basicThermo::e() in "/opt/software/openfoam/public/OpenFOAM/Git/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#3 main in "/opt/software/openfoam/public/OpenFOAM/Git/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linux64GccDPOpt/sonicDyMFoam"
#4 __libc_start_main in "/lib64/libc.so.6"
#5 Foam::regIOobject::writeObject(Foam::IOstream::str eamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const in "/opt/software/openfoam/public/OpenFOAM/Git/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linux64GccDPOpt/sonicDyMFoam"
Stopped

Any help you can provide will be kindly appreciated.

Hi abminternet,
maybe you can try running the debugger version. :eek:

Hi Challenger,

I really don't think that recompiling OpenFOAM again is the best solution.

Hi,
Have you made any changes to the code?

Basically what the error implies is that the constructor of internal energy(e) is being called somewhere in the code. But the thermophysical model being used in sonicdymfoam never calls this constructor and hence 'e' is never implemented during the execution of the code.

You may be calling this function somewhere but the thermophysical model doesn't allow this.

You may provide some more details regarding the thermophysical setup you are using to get more precise advice.

Hi Nakul,

I haven't made any changes to the code. In fact, in line 75 there is an "#include eEqn.h", could it be here where e() is being called?

Thanx for the reply,

Hi,
Right now I am not the pc with OF installed. The header file eEqn.H is where most probably the code for handling the 'energy equation' is written.

If you haven't made any change in the code then look where e() is being called. Most probably it would be called in createFields.H. Alternatively you may post your createFields.H here so that I can have a look.

Hi Nakul,

sure thing, my createFields.H looks like this:

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);


As you mentioned, e() is being called here, but this is the original code, i checked the code online and it has e() too, does that mean that there is an error in the original code?

Hi,

The code is correct. What I understand is that the "thermodynamics package" that you have chosen is not initialising the variable e. You have chosen a package which does all the calculations based on enthalpy and e is not required.

But due to the code e() is being called and hence the error. So you should decide whether internal energy is required by you or not.

Now there are two ways :
1) Change the thermodynamics package and involve some internal energy based calculation. I think eConstThermo instead of hConstThermo may do the trick.

or

2) You may comment out the line calling e() in createfields.H and recompile the solver. But do make sure that the object 'e' is not being used anywhere.

Alternatively a far lesser complicated way is to refer a tutorial of sonicDymFoam and see what thermodynamics package is being used there. As I am unable to access OF presently so I don't know if a tutorial for sonicDymFoam exists or not. You can however google it or can also get some hints by looking at sonicFoam's tutorials.

Whatever you do please post your findings here,

I'm having the same issue as abminternet. I'll try playing with the code, but the original reason I went to hPsiThermo + hConstThermo is that ePsiThermo + eConstThermo was crashing on the calculation of e for my particular sim. (Non-convergence errors.... I was hoping the enthalpy could be reasonable even if the internal energy was getting close to a singularity.)

I haven't found any tutorials for sonicDyMFoam. Do you have a link? The tutorials for sonicFoam use eConstThermo, which is why I started with that.

I also tried hPsiThermo + eConstThermo, but that's not a valid pairing.

simple remove of e() reference insufficient
 

So, it looks like e() does get used, but maybe it shouldn't be?

When I run wmake from the sonicDyMFoam directory, output is as follows:

olorin:/opt/openfoam171/applications/solvers/compressible/sonicDyMFoam # wmake
\SOURCE=sonicDyMFoam.C ; g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-40 -I../sonicFoam -I/opt/openfoam171/src/thermophysicalModels/basic/lnInclude -I/opt/openfoam171/src/turbulenceModels/compressible/turbulenceModel -I/opt/openfoam171/src/finiteVolume/lnInclude -I/opt/openfoam171/src/dynamicMesh/lnInclude -I/opt/openfoam171/src/meshTools/lnInclude -IlnInclude -I. -I/opt/openfoam171/src/OpenFOAM/lnInclude -I/opt/openfoam171/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linuxGccDPOpt/sonicDyMFoam.o
In file included from sonicDyMFoam.C:74:0:
../sonicFoam/eEqn.H: In function ‘int main(int, char**)’:
../sonicFoam/eEqn.H:4:23: error: ‘e’ was not declared in this scope
/opt/openfoam171/src/finiteVolume/lnInclude/readPISOControls.H:8:10: warning: unused variable ‘momentumPredictor’
/opt/openfoam171/src/finiteVolume/lnInclude/readPISOControls.H:11:10: warning: unused variable ‘transonic’
/opt/openfoam171/src/finiteVolume/lnInclude/readPISOControls.H:14:9: warning: unused variable ‘nOuterCorr’
make: *** [Make/linuxGccDPOpt/sonicDyMFoam.o] Error 1

advice?

I'm going to try a couple other thermodynamics models...

solution is unrelated
 

Someone mentioned that simulations tend to act funny if grid cells get aspect ratios > 4. That turns out to be a major problem with my setup. I changed up the mesh to turn down the spatial resolution in some spots, aiming for cells that don't change much in size (<1.2 ratio between widths of neighboring cells) and have small aspect ratios (<4)... sim was able to run a lot longer.

I'll eventually need the higher spatial resolution, but it looks like I'll be playing with overlapping patches and non-rectangular grids rather than tweaking the thermodynamics.

Can you provide some more details about the case and maybe then I might be able to help you with your problem?

Hiyas, nakul.

Not sure if you were addressing me or abminternet or both...

The following is my blockMeshDict. Decreasing the resolution let me run out to the 80 us end time, which was my initial goal. The "poppet" moves toward negative x at a constant -25 m/s. I'm declaring this working for the moment. My next step is to learn some more advanced-meshing techniques (non-rectangular grids, overlapping patches, and so on) in hopes that I can resolve the changing geometry without going over the aspect-ratio limit I mentioned above. (My previous failing runs had aspect ratios greater than 11.)

Cheers

Hi SMesser,

Right now I am not on my workstation with OF installed. But it would be good if you could provide a pic of your mesh.

Secondly, if you are getting accurate results then why you want to increase skewness in your current mesh? Your mesh is good enough if its giving you results!!

Finally if you actually want to mesh something complex where you can't avoid skewness then let me suggest that blockMesh utility may not be the best option for you. You may try using snappyHexMesh utility, which is more efficient or you can even try commercial meshing softwares like gridgen.They may generate good quality mesh even for very complex geometries.

If you have any problems with case setup do let me know!!

An image should be attached.

One section of the mesh is only 4 cells across, from one wall to the opposite - and that doesn't seem like enough cells to get good spatial resolution. (In the image, this is the region which is at lowest pressure.) When I ran with 20 cells across this region, the simulation crashed as noted above. The mesh was the only thing that changed, and since the aspect ratio was well in excess of what others have told me is a reasonable upper limit, I'm assuming the aspect ratio is the problem.

I said it runs. I didn't say it was accurate.

The geometry isn't all that complex, but it changes - which means the aspect ratios of grid cells can change substantially. Ideally I'd start the simulation at zero distance between two sections, and run it until the moving part bounces off the far wall and returns to its original position. That means that in a full run, the aspect ratio of the grid cells will hit infinity on three separate occasions. Given that I've had trouble with aspect ratio 11, I suspect infinity may be overly large.

Thus I'm looking for tools which might allow a dynamic _number_ of cells, or which would otherwise do sneaky things with the cell geometry. (Maybe there's a way to have the grid flow around corners? Sort of a hybrid between Eulerian & Lagrangian dynamics?) My understanding of snappyHexMesh is that it deals with spatially complicated boundaries, but isn't really focused on dynamic geometry.

The other challenge I'll be facing is trying to decrease the pressure in the downstream portion of the simulation. Reality has it at vacuum. The pictured simulation has it at half the maximum density. When I've tried to decrease the pressure via setFields, I've gotten crashes - but I don't know if that's due to the choice of solvers or thermodynamic models. I tried using setFields to introduce stepwise changes to minimize the ratio across any one gridline, but my initial attempt there failed.... Do you know of any workarounds for large pressure differences?

Thanks

Sarah,

Do you have changes in mesh connectivity? Or is it just mesh-motion?

As it stands, it's just mesh-motion, but I need changes in connectivity.

In the image posted above, you can see the mesh is continuous from one end of the device to the other. When the valve is closed, there'll be a break in the middle. (I.e. the grid will not be simply connected as the narrowest channel in the image starts at zero width.)

Since the poppet is never far from the orifice and since its motion will influence gas flow, I don't think just changing face / patch boundary conditions will be sufficient... but I don't know of appropriate examples.

Thanks.

Dynamic layering should work just fine in your case. You can also maintain cell aspect ratios / thickness. You would probably have to approximate opening / closure events using attach/detach sliding-interfaces. Take a look at the movingConeTopo tutorial and the engine classes in 1.6-ext.

So I downloaded OpenFOAM-1.6-ext_kubuntu-10.04.1.iso from Sourceforge, but it doesn't seem to have a "movingConeTopo" case in it, just a bunch of papers which talk about things various folks have done with OpenFOAM. Only a few examples, though, of how they were done. (The various engine cases seem to be just pictures and text - no code.)

Google gives me several references to movingConeTopo, but none of them seem to include code proper.

Could you provide links to relevant code, so that I know what to do with the dynamicMeshDict, etc.?

Thank you

Found OpenFOAM movingTopoCase at http://openfoam-extend.git.sourcefor...b77157;hb=HEAD

downloading & investigating now...

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

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:

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

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.

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.

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

If I leave WM_THIRD_PARTY_DIR in place as I've modified it, I get this:
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 ?

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

Thanks

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:

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

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.

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...):

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

*sigh*

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.

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

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:
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.

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.

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:
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:
yields
If I try running the hybridized dynamicMeshDict I built under 1.7.1, I get something about an empty solver table:

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

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

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.

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.

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).

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.

Correct.

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

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

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.

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
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:

Insight is appreciated, as always

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

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

That's now fixed, but I'm running into a dimensions error when I try to run my modded sonicDyMFoam:
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:
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:
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