Menu
▾
▴
#162 pyFoamDisplayBlockMeshDict.py should support blockMeshDict files with variables.
confirmed
None
normal
feature
always
none
A Utility
0.5.4
general
2012-12-27
2012-12-26
No
If I have a blockMeshDict with variables like so:
convertToMeters 1;
length 42.0;
vertices
(
(0 0 0)
($length 0 0)
etc...
pyFoamDisplayBlockMeshDict.py crashes with the following error:
PyFoam WARNING on line 285 of file /usr/local/lib/python2.7/dist-packages/PyFoam/Applications/DisplayBlockMeshQt.py : While reading blockMeshDict.var this happened: float() argument must be a string or a number
Traceback (most recent call last):
File "/usr/local/bin/pyFoamDisplayBlockMesh.py", line 16, in <module>
DisplayBlockMesh()
File "/usr/local/lib/python2.7/dist-packages/PyFoam/Applications/DisplayBlockMeshQt.py", line 747, in __init__
nr=1)
File "/usr/local/lib/python2.7/dist-packages/PyFoam/Applications/PyFoamApplicationQt4.py", line 37, in __init__
exactNr=exactNr)
File "/usr/local/lib/python2.7/dist-packages/PyFoam/Applications/PyFoamApplication.py", line 213, in __init__
result=self.run()
File "/usr/local/lib/python2.7/dist-packages/PyFoam/Applications/PyFoamApplicationQt4.py", line 59, in run
self.setupGUI()
File "/usr/local/lib/python2.7/dist-packages/PyFoam/Applications/DisplayBlockMeshQt.py", line 756, in setupGUI
self.dialog=DisplayBlockMeshDialog(bmFile)
File "/usr/local/lib/python2.7/dist-packages/PyFoam/Applications/DisplayBlockMeshQt.py", line 286, in __init__
raise e
TypeError: float() argument must be a string or a number
This is already fixed in the current development version (not publicly available) and will be in the next release (which I'm targeting for the first half of january)
Can't put out the fix for this as I can't isolate the commits in question in the local repo.
Maybe changing the reading of the block mesh to (look for the appropriate line in PyFoam/Applications/DisplayBlockMeshQt.py):
self.blockMesh=ParsedBlockMeshDict(bFile,
doMacroExpansion=True)
fixes it for you (can't guarantee it as there were some changes to the MacroExpansion)
Will change the bug to fixed once the release is out
Sorry that I didn't mention it in the original post, but I am using latest trunk from svn, and "doMacroExpansions=True" is set already as you suggest.
I'll try again after the next release.