View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000774 | OpenFOAM | Bug | public | 2013-03-13 08:34 | 2015-02-05 12:29 |
| Reporter | nogenmyr | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | centOS | OS Version | 5 |
| Summary | 0000774: dynamicMeshDict not read... | ||||
| Description | in $FOAM_SRC/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C line 56 should be IOobject::MUST_READ not IOobject::NO_READ as currently. If not opened, the dictionary cannot be read by the constructors called upon construction of the velocityComponentLaplacianFvMotionSolver | ||||
| Steps To Reproduce | Change kiva test tutorial from layered to fvMotionSolver | ||||
| Tags | No tags attached. | ||||
|
|
motionSolver_ ( *this, IOdictionary ( IOobject ( "dynamicMeshDict", time().constant(), *this, IOobject::NO_READ, IOobject::NO_WRITE ), engineDB_.engineDict() ) ) This dictionary is constructed from components not from read. If it were forcibly read the settings provided by engineDB_.engineDict() would not be used which doesn't make much sense. |
|
|
Thanks! I see. Pasting the content of my dynamicMeshDict into engineGeometry makes it work as you planned. I was simply fooled by the error message that reads: --> FOAM FATAL IO ERROR: keyword velocityComponentLaplacianCoeffs is undefined in dictionary "/home/user/OpenFOAM/user-2.2.x/run/kivaTest/constant/dynamicMeshDict" file: /home/user/OpenFOAM/user-2.2.x/run/kivaTest/constant/dynamicMeshDict from line 18 to line 34. as if tried to read constant/dynamicMeshDict, when in fact it tried to find velocityComponentLaplacianCoeffs in constant/engineGeometry. Regards, Kalle |
|
|
The message could be corrected by changing the name in the constructor of motionSolver_ but this would clash with the name of engineDict ("engineGeometry"). It would be better if it simple re-used the engineDict but it is derived from it rather holds it as a reference so that won't work. Another option would be to keep the mesh motion controls in dynamicMeshDict rather than in "engineGeometry". |
|
|
I would suggest the latter... but I agree it would be more elegant to have it all in engineGeometry. |
|
|
engineMesh_engineTime_friends.patch (1,858 bytes)
diff --git a/src/engine/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C b/src/engine/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C
index 50ad374..117332b 100644
--- a/src/engine/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C
+++ b/src/engine/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C
@@ -46,7 +46,8 @@ Foam::fvMotionSolverEngineMesh::fvMotionSolverEngineMesh(const IOobject& io)
motionSolver_
(
*this,
- IOdictionary
+ engineDB_.engineIODict()
+ /*IOdictionary
(
IOobject
(
@@ -57,7 +58,7 @@ Foam::fvMotionSolverEngineMesh::fvMotionSolverEngineMesh(const IOobject& io)
IOobject::NO_WRITE
),
engineDB_.engineDict()
- )
+ )*/
)
{
engineDB_.engineDict().readIfPresent("pistonLayers", pistonLayers_);
diff --git a/src/engine/engineTime/engineTime.H b/src/engine/engineTime/engineTime.H
index f80504f..24c2926 100644
--- a/src/engine/engineTime/engineTime.H
+++ b/src/engine/engineTime/engineTime.H
@@ -57,6 +57,9 @@ SourceFiles
#include "dictionary.H"
#include "dimensionedScalar.H"
+class engineMesh;
+class fvMotionSolverEngineMesh;
+
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
namespace Foam
@@ -70,6 +73,8 @@ class engineTime
:
public Time
{
+ friend class engineMesh;
+ friend class fvMotionSolverEngineMesh;
// Private data
IOdictionary dict_;
@@ -95,6 +100,15 @@ class engineTime
//- adjust read time values
void timeAdjustment();
+protected:
+
+ //- Return the engine geometry dictionary
+ const IOdictionary& engineIODict() const
+ {
+ return dict_;
+ }
+
+
public:
// Constructors
|
|
|
Attached is the patch "engineMesh_engineTime_friends.patch" which is only a quick proof of concept that seemed to work for me with OpenFOAM 2.3.x, which is another possible solution beyond the ones presented. The idea is essentially that: 1. The class "engineTime" could share in a protected way a new method "engineIODict()", which provides the dictionary in its original "IOdictionary" form as "const". 2. The class "engineTime" gives friendly permission to the class "engineMesh" to access said "engineIODict()", which in turn could allow derived methods to access said data. 3. In the attached patch the proof of concept is that "engineDB_.engineIODict()" provides direct "const" access to the necessary "IOdictionary" object, therefore no longer needing to create a dummy "IOdictionary" dubbed "dynamicMeshDict". This can be coded in a much better way than the attached patch. But the questions that remain are: a) Is this concept an acceptable solution? b) Or does it goes against a few rules of good coding? |
|
|
Resolved by commit 608145622b826f9ad514dc36f5dfb805708be421 in OpenFOAM-dev |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-03-13 08:34 | nogenmyr | New Issue | |
| 2013-03-13 10:21 | henry | Note Added: 0001988 | |
| 2013-03-13 11:18 | nogenmyr | Note Added: 0001989 | |
| 2013-03-13 11:24 | henry | Note Added: 0001990 | |
| 2013-03-13 12:52 | nogenmyr | Note Added: 0001992 | |
| 2015-02-03 22:28 | wyldckat | File Added: engineMesh_engineTime_friends.patch | |
| 2015-02-03 22:37 | wyldckat | Note Added: 0003665 | |
| 2015-02-05 12:29 | henry | Note Added: 0003693 | |
| 2015-02-05 12:29 | henry | Status | new => resolved |
| 2015-02-05 12:29 | henry | Resolution | open => fixed |
| 2015-02-05 12:29 | henry | Assigned To | => henry |
