-dict argument assumes name starting with './' is relative to the case (instead of pwd) directory

mentioned in commit ca3f2951

E.g. in

IOobject::path() const

there is handling for absolute paths ('/') but not for '.'.

E.g.

This is valid: cd ~ topoSet -case $FOAM_TUTORIALS/incompressible/icoFoam/cavity/cavity -dict system/topoSetDict

but this should fail:

topoSet -case $FOAM_TUTORIALS/incompressible/icoFoam/cavity/cavity -dict ./system/topoSetDict

(since there is no $PWD/system/controlDict)

added bug label

changed milestone to %Version v1706

assigned to @mark

changed milestone to %v1712

Maybe your example was poor since it actually does properly fail for me, but for different reasons. The dictPath.expand() that topoSet.C uses indirectly via the setSystemMeshDictionaryIO.H replaces with the cwd and means the non-existent file is resolved properly. Nonetheless I see what you mean, especially if I use "../path/file".

This means that a file-path in the IOobject constructor that starts with a / or . should be treated similarly as being outside-the-case. This trickles through to the path() as well.

• could add fileName expand into IOobject::fileNameComponents, which might be easier and more convenient than having every caller do it. Or causes mayhem since people lose control?

I'm not actually sure that the string expansion of a leading "./" into cwd is such a great idea after all.

Thoughts @andy?

topoSet fails for me as well (as it should). Better example:

blockMesh -case $FOAM_TUTORIALS/incompressible/icoFoam/cavity/cavity -dict ./system/topoSetDict

No opinion about the expansion.

For me:

• if -case specified all paths should be local to the case path
• if not using -case assume path is local to CWD

For both - still use leading / to bypass

Made the changes, but fails with parallel since we have things like ../constant/polyMesh/ which triggers the mechanism -> Error.

At the moment, it looks best (safest) to continue with things being relative to the case. If we need to cover special things, can still always

-dict $PWD/../../other/path/dictName

mentioned in commit b91bff64

Using the restyled IOobject (commit b91bff64), the following snippet reflected the attempted (and failed) logic: https://develop.openfoam.com/snippets/5

It seems that even if we add in some additional logic, it should normally only be activated by the IOobject constructor with the fileName parameter. However, the information doesn't persist, which means that later checks are easily confused between -dict ../some/path which is external to the case and a normal ../constant/polyMesh for parallel.

please keep tab on #402 (closed)

Could also just add path.toAbsolute() within IOobject::fileNameComponents

Seems logical. If you use the construct-from-fileName we apply filesystem conventions (so relative w.r.t. cwd). Construct-from-components still uses the relative w.r.t. case as before. Let's try.

mentioned in commit a77b501e

Looks like that change fails horribly for cases using the -region option (eg, externalSolarLoad). I vote for reverting this commit and leaving everything as it was. Optionally, we could add in special logic whereby only having a leading ./ or ../ would trigger the behaviour. For example,

fileName path(rawPath);
if (path.startsWith("./") || path.startsWith("../"))
{
    path.toAbsolute();
}

This would allow a distinction between -dict ./mylocalDict and the current -dict system/someDict. It would also be more consistent with what the fileName expand() is currently doing for such input.

Agreed

multiRegionHeaterRadiation from chtMultiRegionSimpleFoam

This fails in develop and works with following change

• faceAgglomerate -region $i -dict constant/$i/viewFactorsDict

feel free to revert.

mentioned in commit 790b7ef4

closed