View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002375 | OpenFOAM | Feature | public | 2016-12-06 15:33 | 2017-01-11 09:26 |
| Reporter | Shorty | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | suspended | ||
| Platform | Linux | OS | Ubuntu | OS Version | 16.04 |
| Summary | 0002375: Add the record of t=0 to the probe files | ||||
| Description | Hey everybody, it would be nice to have, if it is possible to add the first time folder (normally the zero one) to the output of the probe files? Why? If I record the temperatures at several probe positions and plot the result, the first value should be the starting value instead of the first saved one. It should be not a big deal because the function objects are called within runTime.run(). Kind regards, Tobias | ||||
| Tags | functionObject | ||||
|
|
Can you provide a patch to add this functionality? |
|
|
Yes I can, I will check it out the next days. |
|
|
Dear Henry, I added a patch of the two modified files in order to provide the data for t = 0. I checked it with the probes: Probe 0 (0 0.01 0) # Probe 0 # Time 0 273 0.01 285.293 0.015 294.616 Files that are modified: timeControlFunctionObject.C timeControlFunctionObject.H Cheers. |
|
|
In your proposed change the start-time of the run is hard-coded to be '0'; what should happen for cases started at different times? e.g. the engine tutorial case which starts at -180 deg? |
|
|
Ah okay, never had something like that. In that case I will provide a new patch in order to make it user-defined (lookup). Thanks for the hint. |
|
|
I think it would be better to use functionObject "start()" virtual function which is called on start-up rather than reproduce this functionality specifically in this class. |
|
|
Here is the new patch. In order to avoid the problem that you mentioned, we can now read the value "timeInit" to ensure that e.g. the initial condition of -180 is saved. The default value is set to 0. |
|
|
Sorry ... the uploaded patch is not working ... |
|
|
Here it is. In addition some test starting with time -3. # Probe 0 (0 0.01 0) # Probe 0 # Time -3 273 -2.99 285.293 -2.98 304.856 |
|
|
Sorry Henry I did not notice your hint. Yes it would be better to put it into the start() function. I will do it and upload the patch. Thanks. |
|
|
Good morning, do you mean the start() function of the functionObjectList class which calls the read() function of the class? I think that we could put the functionality into the read() function of functionObjectList. Any other suggestions? |
|
|
Sorry for the confusion, I replaced the need for the functionObject::start() with start-up construction so anything you need to do at start-up of the functionObject should be done in the constructor rather than in a "start()" function. What we need is a test in the constructor for the time-step being the first of the run. I will put this in shortly. |
|
|
Ah okay, well in that case you can just move my function to the constructor of the class (the corrected tar.gz). Thanks for adding that to FOAM. |
|
|
It is not clear why you are creating special control structures to write the initial value, also it is not clear why you use foPtr_->write(); rather than call the timeControl::write() function which includes the rest of the control logic: bool Foam::functionObjects::timeControl::write() { if (active() && (postProcess || writeControl_.execute())) { foPtr_->write(); } return true; } which would need to be included in timeControl::saveInitConditions() otherwise. I suggest simply adding a call to write() in the constructor: Foam::functionObjects::timeControl::timeControl ( const word& name, const Time& t, const dictionary& dict ) : functionObject(name), time_(t), dict_(dict), timeStart_(-VGREAT), timeEnd_(VGREAT), nStepsToStartTimeChange_ ( dict.lookupOrDefault("nStepsToStartTimeChange", 3) ), executeControl_(t, dict, "execute"), writeControl_(t, dict, "write"), foPtr_(functionObject::New(name, t, dict_)) { readControls(); write(); } |
|
|
Okay. simply adding the write() function to the constructor will not work because the writeControl_.execute() is false at the beginning and hence we will not call the foPtr_->write(). In order to prevent analyzing if the time is equal to the initial time (that we set), I made the new "saveInitCondition" function to ensure that this function is only called once during a simulation. However, calling Ptr_.write() is related to the fact that write() simply will not be executed at the initial step. If we would use the write() function in the constructor, as you suggested, then we have to manipulate the if statement in the write() function to ensure that the Ptr_->write() is called at the initial time. In order to provide everything the if statement should then look somehow like: bool Foam::functionObjects::timeControl::write() { if (active() && (postProcess || writeControl_.execute() || (timeInit_ == time_.value())) { foPtr_->write(); } return true; } But this will introduce more operations that are not really needed. Catching timeInit_, getting time_.value() and compare both. But it is your decision how to implement it. I hope I explained it well :) |
|
|
I tested "simply adding the write() function to the constructor" and it worked fine for me, could you provide details of the setup you are using and why this doesn't work for you? If there are cases where this does not work more control should be added to the writeControl class to allow the write at startup. Adding "timeInit_" should not be necessary because "Time" already holds an time-step counter which can be used to test for start and restart and testing for exact equality of real numbers not reliable. Also it is not clear if "execute()" should be called before "write()": what happens if the "write()" functions writes data generated by "execute()"? |
|
|
I have tested your proposed change to functionObjects::timeControl with the simpler form of 'write' in the constructor for a range of cases and functionObjects and as expected it works for some but fails for others depending on the availability of the data to write during construction. Adding 'execute()' before 'write()' in the constructor resolves the problem for some but fails for others depending on the validity of the execution at time zero. |
|
|
Waiting for feedback from reporter. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-12-06 15:33 | Shorty | New Issue | |
| 2016-12-06 16:18 | henry | Note Added: 0007423 | |
| 2016-12-07 19:18 | Shorty | Note Added: 0007429 | |
| 2016-12-19 12:37 | Shorty | File Added: timeControlFunctionObject.tar.gz | |
| 2016-12-19 12:37 | Shorty | Note Added: 0007522 | |
| 2016-12-19 13:20 | Shorty | Tag Attached: functionObject | |
| 2016-12-19 15:14 | henry | Note Added: 0007524 | |
| 2016-12-19 15:22 | Shorty | Note Added: 0007525 | |
| 2016-12-19 15:34 | henry | Note Added: 0007526 | |
| 2016-12-19 15:36 | Shorty | File Added: timeControlFunctionObjectUserDefined.tar.gz | |
| 2016-12-19 15:36 | Shorty | Note Added: 0007527 | |
| 2016-12-19 15:38 | Shorty | Note Added: 0007528 | |
| 2016-12-19 15:39 | Shorty | File Added: timeControlFunctionObjectUserDefined_corrected.tar.gz | |
| 2016-12-19 15:39 | Shorty | Note Added: 0007529 | |
| 2016-12-19 15:42 | Shorty | Note Added: 0007530 | |
| 2016-12-20 08:18 | Shorty | Note Added: 0007532 | |
| 2016-12-20 08:56 | henry | Note Added: 0007533 | |
| 2016-12-20 10:34 | Shorty | Note Added: 0007534 | |
| 2016-12-20 11:58 | henry | Note Added: 0007535 | |
| 2016-12-20 13:17 | Shorty | Note Added: 0007536 | |
| 2016-12-20 13:26 | henry | Note Added: 0007537 | |
| 2017-01-07 10:06 | henry | Note Added: 0007604 | |
| 2017-01-11 09:26 | henry | Assigned To | => henry |
| 2017-01-11 09:26 | henry | Status | new => closed |
| 2017-01-11 09:26 | henry | Resolution | open => suspended |
| 2017-01-11 09:26 | henry | Note Added: 0007620 |
