View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002525 | OpenFOAM | Feature | public | 2017-04-10 08:50 | 2017-11-05 11:03 |
| Reporter | attesz86 | Assigned To | henry | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | dev | ||||
| Summary | 0002525: [Feature request] Time derivative as postProcess function | ||||
| Description | I would like to file a feature request for a postProcessing utility time derivative of scalar fields. The aim is to postprocess the dp/dt field and visualize for acoustic wave propagation applications. | ||||
| Tags | time derivative | ||||
|
|
Can you contribute this functionObject? It would be quite straight forward to write starting from one of the existing field functionObjects which evaluate fvc functions. |
|
|
Hi Henry, I will make the functionality next week. If attesz86 do it before, I am fine too :) |
|
|
Henry, Shorty, I am not experienced in programming (yes, its a shame), so I would pass this to Shorty. Thanks in advance! |
|
|
Hi @Henry and Bruno (@wyldckat) is there some special technique I have to do, in order to get new function lib added to the postProcess tool? I added the new library to the fieldFunctionObjects lib and recompiled it as well as the postProcess tool. However, doing postProcess -list I do not see the new function. In addition I compiled everything again using Allwmake -update in the $WM_PROJECT_DIR. However, still the new library does not be shown in the list. In addition one interesting fact is, that if I remove e.g. the MachNo library from the fieldFunctionObjects library, wclean it and recompile it again as well as the postProcess tool, the MachNo library still exist. Something I am doing wrong. |
|
|
You'll need a file in "etc/caseDicts/postProcessing" for postProcess to be able to run your function object. I would guess the "fields" subdirectory would be appropriate in this instance. Look at "fields/div". |
|
|
@will, thank you - that was exactly the problem. Now I can check it out. |
|
|
@attesz86, would it be possible to sent me some test case in order to check my implementation? |
|
|
@Shorty, I don't really have a validation case for this, but I have a exhaust muffler case that can be used to check it. Can you send me a mail to attila.felfoeldi@cfd-freelancing.com? Thanks! |
|
|
Hi all, the library is working fine with the fvOption included in the control dict but not with the postProcess utility. Using the last one, the fields are zero all the time. I guess it is based on the fact that the oldTime step is not stored. |
|
|
Or lets say, there is no information about the old time step at all. |
|
|
Okay, it is based on the fact that the prev time step is the same as the actual one if we use the postProcess utility. Any ideas how to get rid of that problem? |
|
|
> but not with the postProcess utility Correct, it is not possible in general to calculate the time derivative as a post-process, it would require the previous time step to be saved and read in for each time-step processed which is not practical. |
|
|
Okay, I could make a workaround to check weather the previous and actual one is equal (postProcess call) and make the last time step based on the previous time folder. What do you think Henry? I can upload the actual contribution but it will only work for the fvOptions in the controlDict not for the postProcess utility. However, if one wants to use it with the postProcess utility, it would allow us to check out if a field is steady-state or not :) |
|
|
I would simply check functionObject::postProcess and if it is true issue a warning and deactivate the functionObject. |
|
|
Here the contribution. I added a WarningInFunction if the library is executed by the postProcess utility. |
|
|
Hi all, I added the functionality to use the postProcess tool in combination with the new developed ddt library. This allows one to calculate the time derivatives after the simulation (as it was intended by @attesz86). Therefore, I implemented a new functionality to the GeometricField class in order to direct manipulate the saved old time of the GeometricField by using an argument: myField.storeOldTime(theOldField); @Henry, if you want to have this contribution, let me know. I will upload the patch with all files and update the header-file of the ddt with some comments and how to use it (as it is done in all other functions). Maybe this feature (storeOldTime(GeometricField<>&)) can be useful somewhere else too. Tobi |
|
|
The old time steps are only stored for time derivatives higher than 1 and would only allow first order evaluation when read because only the current and previous time-steps would be available which would be inconsistent with the original run. If the solver were changed to store more old time fields or a functionObject written to do this wouldn't it be better to store the time derivative directly from the run? |
|
|
Thank you shorty for your contribution! henry, it would be indeed better to store the ddt on the fly, also in terms of sampling frequency. However, in case of expensive acoustic simulations the postprocessing utility is good to have. |
|
|
I agree that the time derivative calculation is inconsistent compared to the original run (based on missing information). I guess it depends on what one wants to to with the time derivative analyze. a) The real time derivative can only be achieved during the run (based on the available and accurate solution - so it is only possible with fvOptions) b) The "pseudo/averaged" time derivative could be calculated after the simulation using the postProcess tool. The purpose to do this: E.g. my colleague has a slow changing field (Lorenz Force Field) while other fields are changing faster. The postProcess library gives him the ability to calculate the time derivative of the slow changing field, otherwise the time derivative is almost zero (based on slow change). c) Checking steadyState behavior Actually, I agree with your doubts about inaccuracy and inconsistency if one uses the postProcess tool, but it depends what one wants to do. Additionally, one remark: You are right, the postProcess will be limited to "pseudo 1st order" (because only two time folders are available). However, maybe @attesz86 can give some information about - why we need it in the postProcess application. Nevertheless, the application is now able to be executed with the postProcess tool too, while using an new implemented function to the GeometricField class. I will attach the contribution. |
|
|
@attesz86 > Thank you shorty for your contribution! henry, it would be indeed better to store the ddt on the fly, also in terms of sampling frequency. This is already available using the fvOptions. |
|
|
Calculating ddt with the postProcess tool is not generally possible, practical or accurate as already discussed. The best option would be to use the proposed functionObject to write ddt of the specified field for the selected write frequency during the run. |
|
|
Using the writeControl enables one to save the fields as one would like. So I think that everything is fine. I might put the extended version to an own repository. @Henry, do you need something else? The patch given in the tar file is fine then. |
|
|
> do you need something else? You have provided everything I need, I just haven't had time to work on it. I hope to do this over the weekend. |
|
|
Okay perfect. For those (@attesz86) who want to use the extended version with the postProcess application should go to https://bitbucket.org/shor-ty/ddtextended |
|
|
Hi Tobi, I am checking through the code you provided and wondering why it is limited to scalar and vector fields, why not support all field type? |
|
|
I couldn't see any reason why the other field types should be ommited so I added them and it seems to run fine. |
|
|
Resolved by commit c2835a450b2990a8d2d496ad3507f81ba743ea08 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-04-10 08:50 | attesz86 | New Issue | |
| 2017-04-10 08:50 | attesz86 | Tag Attached: time derivative | |
| 2017-10-20 11:46 | henry | Note Added: 0008903 | |
| 2017-10-25 08:15 | Shorty | Note Added: 0008930 | |
| 2017-10-25 08:57 | attesz86 | Note Added: 0008931 | |
| 2017-10-25 10:26 | Shorty | Note Added: 0008932 | |
| 2017-10-25 11:04 | will | Note Added: 0008933 | |
| 2017-10-25 11:13 | Shorty | Note Added: 0008934 | |
| 2017-10-25 12:49 | Shorty | Note Added: 0008935 | |
| 2017-10-25 15:09 | attesz86 | Note Added: 0008941 | |
| 2017-10-30 16:29 | Shorty | Note Added: 0008957 | |
| 2017-10-30 16:29 | Shorty | Note Added: 0008958 | |
| 2017-10-30 16:49 | Shorty | Note Added: 0008959 | |
| 2017-10-30 16:57 | henry | Note Added: 0008960 | |
| 2017-10-30 18:07 | Shorty | Note Added: 0008961 | |
| 2017-10-30 18:32 | henry | Note Added: 0008962 | |
| 2017-10-30 19:17 | Shorty | File Added: ddt.tar.gz | |
| 2017-10-30 19:17 | Shorty | Note Added: 0008963 | |
| 2017-11-01 18:06 | wyldckat | Assigned To | => henry |
| 2017-11-01 18:06 | wyldckat | Status | new => assigned |
| 2017-11-03 09:54 | Shorty | Note Added: 0008985 | |
| 2017-11-03 10:01 | henry | Note Added: 0008987 | |
| 2017-11-03 10:20 | attesz86 | Note Added: 0008988 | |
| 2017-11-03 10:25 | Shorty | Note Added: 0008989 | |
| 2017-11-03 10:27 | Shorty | Note Added: 0008990 | |
| 2017-11-03 10:31 | henry | Note Added: 0008991 | |
| 2017-11-03 10:45 | Shorty | Note Added: 0008992 | |
| 2017-11-03 10:56 | henry | Note Added: 0008993 | |
| 2017-11-03 11:27 | Shorty | Note Added: 0008995 | |
| 2017-11-05 10:43 | henry | Note Added: 0009000 | |
| 2017-11-05 11:03 | henry | Note Added: 0009001 | |
| 2017-11-05 11:03 | henry | Status | assigned => resolved |
| 2017-11-05 11:03 | henry | Resolution | open => fixed |
| 2017-11-05 11:03 | henry | Fixed in Version | => dev |
| 2017-11-05 11:03 | henry | Note Added: 0009002 |
