|
[Sponsors] |
objectRegistry motionU in subsetMotionSolver error |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
November 8, 2011, 10:58 |
objectRegistry motionU in subsetMotionSolver error
|
#1 | |
Senior Member
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 18 |
Hi all,
to modify the motionU file within my solver (modified interDymFoam), I successfully use Code:
tetPointVectorField& motionU ( const_cast<tetPointVectorField&>(mesh.lookupObject<tetPointVectorField>("motionU")) ); Quote:
Arne Last edited by Arnoldinho; November 9, 2011 at 05:35. Reason: 'serial' added |
||
November 12, 2011, 15:02 |
|
#2 |
Member
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 16 |
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 |
|
November 15, 2011, 03:51 |
|
#3 |
Senior Member
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 18 |
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 |
|
November 30, 2011, 07:39 |
|
#4 |
Member
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 16 |
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 |
|
December 5, 2011, 15:46 |
|
#5 |
Senior Member
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 18 |
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 |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[swak4Foam] GroovyBC the dynamic cousin of funkySetFields that lives on the suburb of the mesh | gschaider | OpenFOAM Community Contributions | 300 | October 29, 2014 19:00 |
c++ libraries and solver compiling | vaina74 | OpenFOAM Installation | 13 | February 3, 2012 18:43 |
Errors running allwmake in OpenFOAM141dev with WM_COMPILE_OPTION%3ddebug | unoder | OpenFOAM Installation | 11 | January 30, 2008 21:30 |
DecomposePar links against liblamso0 with OpenMPI | jens_klostermann | OpenFOAM Bugs | 11 | June 28, 2007 18:51 |
user defined function | cfduser | CFX | 0 | April 29, 2006 11:58 |