2017-06-25 06:19 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002396OpenFOAM[All Projects] Bugpublic2017-01-05 23:19
ReporterMattijsJ 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformGNU/LinuxOSOpenSuSEOS Version13.2
Product Versiondev 
Target VersionFixed in Version 
Summary0002396: dictionary scoped look up too forgiving?
DescriptionFollowing dictionary:

someDict
{
    subDict
    {
        myKey myValue;
    }
}

geometry
{
    $:someDict2.subDict; // note: someDict missspelled
}

in v3/v4 it complains that there is no 'someDict2' entry at the top level
in dev it does not complain but just takes it for a non-existing entry called 'someDict2.subDict'. This is because in dev we extended the lookup at any level to include words with a '.' (to e.g. handle key 'motorBike.stl'). Hmm. Any suggestions?

TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0007487

wyldckat (updater)

I didn't take a proper look at the implementation that was done, but I had gotten the impression that names with dots were only valid if they were in quotes.

The other possibility is to go the same way that regular expressions do their job: a dot is a dot only when escaped with a backslash, e.g.:

  $:someDict.subDict
  $:someDict.motorbike\.stl

~0007489

MattijsJ (reporter)

Quotes makes dictionary entries wildcards which are stored completely separate and have separate matching rules.

Backslash: it is pretty exceptional that we're trying to use '.' in a word used for looking up things in a dictionary so a special interpretation of the keyword is not a big problem. Attached dictionary.C that implements it:

foamDictionary ./snappyHexMeshDict -entry 'geometry.motorBike\.obj'

Feel free to test & break it.

~0007497

MattijsJ (reporter)

With that version recursive substitution still works as long as the word includes the '\':

    motorBike.obj 10;

    var motorBike\.obj;

    b ${$var};

produces

    b 10;

~0007500

chris (manager)

Last edited: 2016-12-16 10:55

View 2 revisions

The real problem is that motorBike.obj should never be a keyword. Syntax in snappyHexMeshDict, surfaceFeatureExtractDict, that uses the filename as a keyword is inconsistent.

motorBike.obj
{
    type triSurfaceMesh;
    name motorBike;
}

should be

motorBike
{
    type triSurfaceMesh;
    name motorBike.obj; // or filename motorBike.obj
}

The filename should not be one level higher than the type because the need for a filename is a consequence of the type being triSurfaceMesh.

Same with surfaceFeatureExtract, where the consequences for the user are much worse because of the need to have a separate dictionary for every surface.

motorBike.obj
{
    extractionMethod extractFromSurface;
...

Here, the dictionary name could be the method, and the dictionary include an entry for all surfaces, e.g.

extractFromSurface
{
    surfaces (motorBike.obj anotherSurface.obj);
...

~0007538

MattijsJ (reporter)

Attached triSurfaceMesh[CH] to accept

motorBike
{
    type triSurfaceMesh;
    fileName "motorBike.obj";
}

~0007539

MattijsJ (reporter)

triSurfaceMesh.C

~0007540

mark (reporter)

Isn't the problem that a '.' is a valid word character and thus automatically a valid character for a keyword, but the '.' has also been double-purposed as a scoping character?

IMO a consistent solution would be to have '/' as the scoping character, which is definitely not a valid word character and require surrounding scoped variables with ${ }.

~0007598

chris (manager)

Allowing "." as a valid keyword character was arguably not ideal, but we probably need to live with it.

As far as I can tell, it is only included as a character in keywords that are:
1) filenames, e.g. motorBike.obj
2) fields of particular phases, e.g. alpha.water, T.steam

Using filenames as keywords is bad design. I suggest that is eliminated throughout the code.

That leaves only fields of phases as the one exception, which I propose we handle with "\." unless that causes some kind of critical failure.

PS Surely it is too late for "/" as the scoping character? which was considered, but rejected as a confusing scoping character. I cannot recall whether using "_" for fields of phases, e.g. alpha_water, was only rejected because of p_rgh, but I guess that would have been better.

~0007600

wyldckat (updater)

I've thought about this as well and forgot to write down sooner what I've remembered/associated so far, also because I still wanted to double-check some of these possibilities.
Either way, before it's too late, adding to what Chris has already listed, here are the additional situations that may need to be kept in mind:

 - Using slash '/' as a scoping character could potentially lead to problems when using '#calc', although I haven't tested yet if it even supports these scoped variables; but I guess that using '${}' would have solved that issue, as Mark mentioned.

 - There is a particular type of object/file naming convention which may also interfere with the parsing of the scopes, for example, names such as 'thermo:psi' and 'cloudname:UCoeff'. I haven't checked how these are parsed/interpreted, but could potentially conflict with the colon as a prefix (e.g. '$:thermo:psi.boundaryField.inlet.value').

 - Using the new convention to have file names explicitly defined through a keyword, is a big advantage for people who work a lot with CAD and then have file names like "30+-0.1mm washer.stl", which would be a nightmare when trying to mesh a few hundred or more of them with 'snappyHexMesh'.
+Notes

-Issue History
Date Modified Username Field Change
2016-12-15 12:41 MattijsJ New Issue
2016-12-15 12:46 wyldckat Note Added: 0007487
2016-12-15 18:02 MattijsJ File Added: dictionary.C
2016-12-15 18:02 MattijsJ Note Added: 0007489
2016-12-16 10:05 MattijsJ Note Added: 0007497
2016-12-16 10:21 chris Note Added: 0007500
2016-12-16 10:55 henry Note Edited: 0007500 View Revisions
2016-12-20 16:00 MattijsJ File Added: triSurfaceMesh.H
2016-12-20 16:01 MattijsJ File Added: triSurfaceMesh-2.H
2016-12-20 16:01 MattijsJ Note Added: 0007538
2016-12-20 16:01 MattijsJ File Added: triSurfaceMesh.C
2016-12-20 16:01 MattijsJ Note Added: 0007539
2016-12-20 21:01 mark Note Added: 0007540
2017-01-05 17:20 chris Note Added: 0007598
2017-01-05 23:19 wyldckat Note Added: 0007600
+Issue History