|
[Sponsors] |
changeDictionary messes it up when #include directive is used |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
February 1, 2015, 23:34 |
changeDictionary messes it up when #include directive is used
|
#1 |
Senior Member
Alex
Join Date: Oct 2013
Posts: 337
Rep Power: 22 |
Hello,
I'm working in a chtMultiRegion case and, as it is usual in these kind of cases, I have to use changeDictionary to set up boundaries after creating the geometry with blockMesh and topoSet. So far, no problem. However, in this case I want to make use of the #include directive in order to use some values stored in a particular folder. I want to do that because some values are very common among all regions (and they are a few...) and I have to do a good amount of simulations switching them, so if I could only change the values from the file stored in an outter folder it would be very nice... The problem is that it seems that changeDictionary is not capable to handle the #include statement. I will show you how I used it and the results it gave me: ·changeDictionaryDict where I used #include dirctive: Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.3.0 | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object changeDictionaryDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dictionaryReplacement { boundary { } T { #include "$FOAM_CASE/include/initialCond_sum" internalField uniform $Tini; boundaryField { ".*" { type symmetry; value $internalField; } ..... } Code:
dimensions [ 0 0 0 1 0 0 0 ]; internalField uniform 300; boundaryField { .... patch[i] { type externalWallHeatFluxTemperature; value $internalField; kappa solidThermo; Ta uniform $Tin; h uniform 2; thicknessLayers ( ); kappaLayers ( ); kappaName none; QrName none; } .... } #include "$FOAM_CASE/include/initialCond_sum" internalField uniform $Tini; Code:
--> FOAM FATAL IO ERROR: Illegal dictionary entry or environment variable name "Tin" Valid dictionary entries are 3 ( type value kappa ) file: path_to_ file 0/region/T.boundaryField.patch[i] from line 36 to line 38. From function primitiveEntry::expandVariable(const string&, const dictionary& in file db/dictionary/primitiveEntry/primitiveEntry.C at line 96. FOAM exiting I also tried to put the statement in an upper position like outside the T keyword or even above the dictionaryReplacement keyword, but OpenFOAM complained either way. Actually, in any of the last cases the utility crushes and no dictionary is replaced. Any word of advice will be very welcome. Regards, Alex
__________________
Web site where I present my Master's Thesis: foamingtime.wordpress.com The case I talk about in this site was solved with chtMultiRegionSimpleFoam solver and involves radiation. Some basic tutorials are also resolved step by step in the web. If you are interested in these matters, you are invited to come in! |
|
February 4, 2015, 19:05 |
Not trying to spam, just asking...
|
#2 |
Senior Member
Alex
Join Date: Oct 2013
Posts: 337
Rep Power: 22 |
Any idea on what the problem could be? Or directly changeDictionary utility can not handle properly the #include directive? May it be a bug?
__________________
Web site where I present my Master's Thesis: foamingtime.wordpress.com The case I talk about in this site was solved with chtMultiRegionSimpleFoam solver and involves radiation. Some basic tutorials are also resolved step by step in the web. If you are interested in these matters, you are invited to come in! |
|
February 5, 2015, 16:09 |
|
#3 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,981
Blog Entries: 45
Rep Power: 128 |
Hi Alex,
If you run changeDictionary with the "-help" option, you should see this line: Code:
-literalRE treat regular expressions literally (i.e., as a keyword) Let us know if this works as intended. I do vaguely remember having problems with this as well in the past, but it was with an older version of OpenFOAM... not sure which one. Best regards, Bruno
__________________
|
|
February 5, 2015, 20:26 |
|
#4 | |
Senior Member
Alex
Join Date: Oct 2013
Posts: 337
Rep Power: 22 |
Quote:
Thanks for your tip. However, after running the command changeDictionary -help the correct options seems to be Code:
-enableFunctionEntries enables expansion of dictionary directives - #include, #codeStream etc Regards, Alex
__________________
Web site where I present my Master's Thesis: foamingtime.wordpress.com The case I talk about in this site was solved with chtMultiRegionSimpleFoam solver and involves radiation. Some basic tutorials are also resolved step by step in the web. If you are interested in these matters, you are invited to come in! |
||
February 6, 2015, 11:59 |
|
#6 |
Senior Member
Alex
Join Date: Oct 2013
Posts: 337
Rep Power: 22 |
Quick answer : I'm using 2.3.x version
__________________
Web site where I present my Master's Thesis: foamingtime.wordpress.com The case I talk about in this site was solved with chtMultiRegionSimpleFoam solver and involves radiation. Some basic tutorials are also resolved step by step in the web. If you are interested in these matters, you are invited to come in! |
|
February 7, 2015, 04:33 |
|
#7 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,981
Blog Entries: 45
Rep Power: 128 |
Hi Alex,
Sorry, I re-read now the post you had written and yesterday I thought you were still having problems in using changeDictionary. I quickly had thought of this because that option is provided on older versions of OpenFOAM and I very vaguely remember that the option "-enableFunctionEntries" didn't always work as intended... mmm, possibly because back then I actually wanted to preserve the original includes... Anyway, I'm glad you've figured out the option you needed Best regards, Bruno |
|
February 7, 2015, 15:06 |
|
#8 | |
Senior Member
Alex
Join Date: Oct 2013
Posts: 337
Rep Power: 22 |
Quote:
I also wanted that the include line was copy-pasted literally instead of substituting its values in the new dictionary, but as far as I saw the effect is the same since the macro substitution is done correctly. I also tried to use both "-enableFunctionEntries" and "-literalRE" at a time, the problem is that as it copy-pastes literally the regular expressions instead of interpreting them. Thus, it copied the character ".*" directly to the new file so all the boundaries that were to be found under the ".*" were changed to "calculated" instead... Best regards, Alex
__________________
Web site where I present my Master's Thesis: foamingtime.wordpress.com The case I talk about in this site was solved with chtMultiRegionSimpleFoam solver and involves radiation. Some basic tutorials are also resolved step by step in the web. If you are interested in these matters, you are invited to come in! |
||
Tags |
changedictionary, chtmultiregionfoam, include |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
cyclic boundary conditions for FSI | kanuk | OpenFOAM Programming & Development | 10 | April 25, 2014 03:52 |
OpenFoam install script Error during paraFoam installation | SePe | OpenFOAM Installation | 10 | June 19, 2010 16:15 |
critical error during installation of openfoam | Fabio88 | OpenFOAM Installation | 21 | June 2, 2010 04:01 |
Problems in compiling paraview in Suse 10.3 platform | chiven | OpenFOAM Installation | 3 | December 1, 2009 08:21 |
OpenFOAM15 paraFoam bug | koen | OpenFOAM Bugs | 19 | June 30, 2009 11:46 |