Time selection in FoamToEnsight utility
Hello,
I would like to understand how works the time selection in foamToEnsight utility. In the beginning I thought that the new timeSelctor features were available, but finally it is not (no way to use the option -time 0.1:0.2 for instance). It seems to use the controlDict keywords startTime and endTime, at least that is what I understood from the source file, but by testing I am not convinced: in a case containing 4 time directories, changing startTime and/or endTime always results in the processing of all available time directories. Does anyone have a hint ? Thanks! melanie |
Quote:
The main issue with adding the timeSelector to the existing foamToEnsight is that this utility always removes an existing "EnSight" directory at the start, always writes the geometry and writes a *.case file. Thus if you wanted to convert things incrementally, for example, Code:
foamToEnsight -time time1:time2 In contrast, the foamZoneToEnsight utility is designed to allow incremental conversion. It not only leaves the ensight directory intact, but will attempt to reduce the number of times the geometry file is written (it uses a file cache with the foam->ensight geometry mapping). But doesn't work in parallel. |
Thanks Mark.
Yes, I noticed that each call to foamToEnsight utility removes the existing EnSight directory. I downloaded your foamZonesToEnsight utility from an old thread, and compilation only produced one error: in OF-1.6 there is no addTimeOptionsNoConstant.H file. Did you compile it on OF-1.6? Anyway, I will try to modify the existing foamToEnsight utility to keep the parallel advantage, and I will see if I am also able to get it writing in an existing directory without removing it. melanie |
Quote:
Quote:
If you had time though, I think it would be better just to add a -reconstruct option to foamToEnsightParts (eg, by stealing code from reconstructPar). This would allow you to convert existing parallel results to ensight as a serial process (eg, on your workstation) without having to startup a separate parallel process. |
I did several tries with foamToEnsightParts, and I found some issues. The first point is that this utility is unable to work on time data created with the writeFieldsOften functionObject, since the uniform/time file is not present in this case. Moreover, I need to have Ensight data written in a list, without time directories, of the form
This is a naming convention closer to that used by foamToEnsight utility actually. And indeed, as you mentioned, I would need to add a -reconstruct option to post-process my data. In the end, I don't know what is the easier thing, modify one or the other utility... Regarding the -reconstruct option, are you aware of a utility that performs such a reconstruction as a pre-step ? |
Quote:
Quote:
Code:
rm -rf Ensight/data/00000* Code:
rm -rf EnSight/rpm-1500.?.* Quote:
I think that adding -reconstructPar to foamToEnsightParts would be the better solution, but adding an '-append' option and the timeSelector to foamToEnsight would probably probably be much faster to do. |
The writeFieldsOften functionObject comes from the simpleFunctionObjects library described on the Wiki here: http://openfoamwiki.net/index.php/Co...vailable_types. I am not sure whether I should submit a bug report since this is not included in the release version, but I am sure Bernhard can hear us :)!
Actually regarding the Ensight file structure, you are right and now I understand your choice, and this is a good choice also for what i'd like to do. Finally I will have to understand the reconstructPar code and classes! Thank you very much for all your advices Mark. melanie |
Quote:
The writeFieldsOften was just intended as a quick hack to .... äh .... write only certain fields often. I therefore never bothered to write the uniform-directory. And AFAIKS this is written in the Time::writeObject-method ... only if Time thinks it is the right time to write it .... something that the functionObject bypasses. So the best guess would be to emulate the uniform-writing stuff in the FO (but ONLY if Time doesn't think that it is write-time) I think we'll move that discussion to the other thread (it's more appropriate there) |
Actually I am answering in this thread because I found a solution in the options of foamToEnsightParts utility. Indeed it is possible to supply a -index option that make the utility ''ignore the time index contained in the time file and use a simple indexing when creating the Ensight files''. This is a very smart feature since it allows to read time directories that do not contain uniform/time file! So I do not need to change the behavior of the functionObject.
I will just have to concentrate on adding a reconstruct option to foamToEnsightParts. Not a tiny thing for me :confused:... ! melanie |
I have done some modifications in foamToEnsightParts.C to treat decomposed data sets. By adding a condition linked to the option -reconstruct
Code:
if (args.optionFound("reconstruct")) Code:
#include "processorMeshes.H" Thanks! melanie |
I'm glad to see you're making progress.
Quote:
Code:
EXE_INC = \ |
Ok, thanks; for the moment I keep the 'dirty' solution and the file linking is working. I was able to compile the utility without errors, the compiling log shows the following:
Code:
tzntgq@caeldh05:~/OpenFOAM/tzntgq-1.6/applications/utilities/postProcessing/dataConversion/foamToEnsightParts_mine> wclean Another issue for me is the variables declaration. Actually I modified the existing foamToEnsightParts code to include the reconstruct option. This option is handled with several if loops like described in my previous message. So for instance in one loop I will assign the variable timeDirs, differently if the reconstruct option is chosen or not: Code:
extern instantList timeDirs; |
Quote:
I would probably do something like this: Code:
|
Quote:
I have corrected the code with your suggestions. Anyway, I cannot see the result since the executable is still not created... do you have an idea of what could be the problem, since compilation shows no warning? (except clock skew issues but this is not important for us). |
Hello,
I am back with a referencing error; actually Mark's suggestion Quote:
melanie |
Today I have a good news: I managed to compile and have something working! This is a first important step for me :)!
Now I still have some troubles. The main issue is that for the reconstruct option to work on decomposed cases, I have to define procMeshes like this: Code:
myProcessorMeshes procMeshes(databases, regionName); I tried to follow the advices given by Mark. But it is complicated to handle... If this is unclear let me know and I post the relevant piece of code! Thanks melanie |
Quote:
Quote:
Code:
autoPtr<procMeshes> myProcMeshes; If you use autoPtr (or any pointer) it should work fine. /mark |
Thanks Mark. I tried your proposition but this does not work; when I implement:
Code:
autoPtr<myProcessorMeshes> myProcessorMeshes; Code:
tzntgq@caeldh05:~/OpenFOAM/tzntgq-1.6/applications/utilities/postProcessing/dataConversion/foamToEnsightParts_mine> wmake Code:
if (doReconstruct) The class is named myProcessorMeshes. I studied this class, but I am unable to write a dummy class to treat serial cases, which would probably be the best solution... |
Quote:
Do you have a typo, or did you really try to use 'myProcessorMeshes' both for the class name and the variable name? But in the reconstruct you have new procMeshes(). What is subclassed from what? I can't figure out what you are doing, but it looks like dangerous programming style. |
Ok, I should have written
Code:
autoPtr<myProcessorMeshes> procMeshes; But still I do not understand the details of the implementation you suggested with the autoPtr, I did not find documentation about this. And I don't know either if there is a subclass in all this. And it still does not work ! Please excuse my mistakes that may seem trivial to you, I am just learning C++ and OF programming... melanie |
Quote:
This might work better, Code:
autoPtr<myProcessorMeshes> procMeshes; |
Thanks again and again Mark, now it is working fine!
Actually I also had to modify the lines where functions of procMeshes are called; since procMeshes is now a pointer and no more a variable, Code:
procMeshes.readUpdate() Code:
procMeshes->readUpdate() Is anyone interested in this utility, either to test and/or to use it? Anyway, many thanks for your patience Mark, I know I got much to learn left on C++ and OF-programming! I think that on the same model, I will modify foamToTecplot utility to include this reconstruction option. melanie |
Quote:
Code:
autoPtr<myProcessorMeshes> procMeshesPtr; Check the autoPtr docs again for information about the autoPtr::operator() methods. |
Hi Melanie, Any more progress to report? /mark |
Hello Mark,
Actually I was able to successfuly correct my code with your latest suggestions. However, about one week after that, the machine on which I used to compile crashed. And on the other machines, I always have a compilation error, even with code written by others (like foamToTecplot utility). I did not post a bug description since I am not sure of where is the problem, OF paths or Linux Suse version, or something else. The real problem is that I am also unable to use the code compiled previously; the same error as on compilation is issued, saying Code:
~/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so: file not recognized: File format not recognized mélanie |
Quote:
What does the 'file' command report? eg, Code:
$ file ~/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so "ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped" If that reports okay, but you still have problems, see if the symbol table looks intact (eg, objdump -t ~/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so). Beyond that it's hard to say what's wrong. |
The answer to the "file" command is:
Code:
ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Code:
File format not recognized |
Quote:
Have you tried recompiling finiteVolume recently? It would probably help (and can't hurt). |
Actually on another machine the reply to the last command is a bit different, and the compilation error is also different. It seems similar to what is reported in this thread so I will firstly try to compile GCC on one of my machines and see if this helps...
|
All times are GMT -4. The time now is 00:11. |