[Arnoldinho]

Hi all,

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

tetPointVectorField& motionU
    (
        const_cast<tetPointVectorField&>(mesh.lookupObject<tetPointVectorField>("motionU"))
    );

in serial and in parallel. To save computational time, I now want to use the subsetMotionSolver (look at this thread http://www.cfd-online.com/Forums/ope...-boundary.html). 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

--> FOAM FATAL ERROR:

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

0
(
)


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?

Arne

[WiWo]

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?

Cheers,
Wolfgang

P.S.: You've certainly already found this small repository of wisdome: http://openfoamwiki.net/index.php/Snip_objectRegistry

[Arnoldinho]

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?

Arne

[WiWo]

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.

Cheers,
Wolfgang

[Arnoldinho]

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

Greetings,
Arne