CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Programming & Development (
-   -   objectRegistry motionU in subsetMotionSolver error (

Arnoldinho November 8, 2011 10:58

objectRegistry motionU in subsetMotionSolver error
Hi all,

to modify the motionU file within my solver (modified interDymFoam), I successfully use


tetPointVectorField& motionU

in serial and in parallel. To save computational time, I now want to use the subsetMotionSolver (look at this thread I am able to create the subset and run my case in normal interDymFoam (serial) without problems. But my own solver using above motionU modification gives



request for tetPointVectorField motionU from objectRegistry region0 failed
available objects of type tetPointVectorField are


From function objectRegistry::lookupObject<Type>(const word&) const
in file /opt/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 140.
I'm not familiar with objectRegistry, so could anyone help me out here?


WiWo November 12, 2011 15:02

Hi Arne,

I've encountered exactly the same problem when trying to implement subsetMotion for my FSI solver just today. I'm also searching for motionU using mesh.objectRegistry::lookupObject<tetPointVectorFi eld>("motionU") ... but nothing is found.

You can verify if an object is registered with an objectRegistry (for example "mesh") by using e.g.
Info << mesh.objectRegistry::foundObject<tetPointVectorFie ld>("motionU") << endl;

I've never given too much thought to the objectRegistry and how exactly it works. But might it be possible that motionU is just not registered with the "mesh" objectRegistry but with some kind of subMesh objectRegistry? After all, motionU is provided in 0/"subsetName" and not in 0/ directly ... and motionU must be registered somewhere, because icoDyMFoam works fine with subsetMotion.

I'll try to figure it out, but it will be a lot of trial & error. Can anybody with more experience in that field probably help?


P.S.: You've certainly already found this small repository of wisdome:

Arnoldinho November 15, 2011 03:51

Thanks Wolfgang,

so I'm not the only one looking at where motionU is 'hiding itself'. I will try to figure it out as well later on by using the foundObject call.
Or did you already get it?


WiWo November 30, 2011 07:39

Hi Arne,

I think I found our little runaway ... it is hidden in another objectRegistry as suspected. I had to learn a bit about how to access and search through this type of things, but as soon as you get the hang of it it's fun :-)

Ok, it seems (I hope I'm not writing too much rubbish here, as the following in purely based on the outcome of my trials and its interpretation) that the highest ranking objectRegistry (runTime) contains at least two entries if you use a subsetMesh. The overall mesh is called "region0" and the subsetMesh carries the name you gave it, e.g. motionSubset in my case (as this is the name I gave the subfolders in 0/ constant/ and system/ which contain the subset-specific data). You can retrieve that info using:

Info << "runTime objectregistry contains: " << runTime.objectRegistry::names() << endl;

Now, doing the same thing for "region0" (which is an fvMesh) and "mesh", you can verify that "mesh" seems to be a synonym for "region0", e.g. they contain the same members (and don't contain motionU):

const fvMesh& primaryMesh = runTime.objectRegistry::lookupObject<fvMesh>("regi on0");
Info << "region0 contains: " << primaryMesh.objectRegistry::names() << endl;
Info << "mesh contains: " << mesh.objectRegistry::names() << endl;

Now, for our friend the motionMesh, this works similarly:

const fvMesh& motionMesh = runTime.objectRegistry::lookupObject<fvMesh>("moti onSubset");
Info << "motionMesh contains: " << motionMesh.objectRegistry::names() << endl;

And there it is, the lost motionU :-) Then you should be able to extract it using:

tetPointVectorField& motionU = const_cast<tetPointVectorField&>
(motionMesh.objectRegistry::lookupObject<tetPointV ectorField>("motionU"));

I found a very recent presentation by Daniele Trimarchi (Uni Southampton) which was quite helpful. Later on, I also discovered that quite exactly the same procedure I explained is actually implemented in the readCouplingproperties.H file of applications/solvers/stressAnalysis/icoFsiFoam ... one is always more clever afterwards.


Arnoldinho December 5, 2011 15:46

Hi Wolfgang,

sorry for not having answered directly. It seems as if you figured it out. Great. I will have a look on it.
Unfortunately (or fortunately) I do not have to use the motionU at the moment. I'm modifying the point positions of the mesh directly based on some calculatiosn and therefore do not need a meshMotionSolver right now. For my specific cases, this works pretty well, and is a lot faster.

But I am sure that I will switch back to it somewhen for different cases...


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