bugCERTI - Bugs: bug #36531, Internal RTI time not reset after...

 
 

bug #36531: Internal RTI time not reset after restore (batch runs)

Submitter:  Joris Steneker <joris>
Submitted:  Wed 23 May 2012 01:52:37 PM UTC
   
 
Category:  CERTI Severity:  * 3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  * 3.4.2
Reproducibility:  Every Time Fixed Release:  * NextRelease
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 14 Jul 2015 03:18:29 PM UTC, comment #3: 

Any chance that this bug will be fixed in the next release (3.4.4)?

Is it an option to use the resignFederationExecution and destroyFederationExecution in combination with a (re)createFederationExecution and (re)joinFederationExecution after each replication as a workaround?

Will the internal CERTI and ambassador clocks be reset and all federation objects are removed from the RTI each time a new replication is initialized?


Joris Steneker <joris>
Tue 03 Jul 2012 07:44:58 AM UTC, comment #2: 

Hi Eric,

Thanks for helping me with the problem.

In the meantime I already looked a bit into the CERTI code with respect to the save/restore methods. It seems that the federate state is saved to a xml file using the method saveXmlData(). This xml file is then read during a federate restore using the method restoreXmlData().
Both methods only seem to save/load information about:
- the federation name and handle
- the federate name and handle
- whether the federate is constrained and/or regulated

No information about the RTI time and/or local federate time seems to be stored. I hope that this can be added.

Joris Steneker <joris>
Mon 02 Jul 2012 04:14:28 PM UTC, comment #1: 

Hi Joris,

I'll try to look into this in a couple of days.
It looks like a bug to me.

Eric NOULARD <erk>
Group administrator
Wed 23 May 2012 01:52:37 PM UTC, original submission:  

Environment:
CERTI 3.4.2
Visual C++ 2008

Description:
I have a simple federation of two timeconstrained and timeregulated federates. The federates are setup such that it is possible to run multiple consequtive simulation runs (batch runs).

At the beginning of the first run (time = t1) the federation state is saved using a requestFederationSave/initiateFederateSave/federateSaveBegun/federateSaveComplete/federationSaved mechanism (one of the federates initiates the save).

After the first run has completed (time = t2 > t1) the state of the federation is restored to the saved state (the state before first run, time = t1) using the requestFederationRestore/requestFederationRestoreSucceeded/federationRestoreBegun/initiateFederateRestore/federateRestoreComplete/federationRestored mechanism (one of the federates initiates the restore).

The issue that I encounter is that the internal time of the RTI is not reset to the time instance at the moment of saving (t1).
(I queried the GALT and it is equal to t2.) It still remains equal to t2. So as soon as one of the federates issues a TimeAdvanceRequest (local time in each federate is reset to t1), the RTI throws an "FederationTimeAlreadyPassed" exception.

Maybe I forgot something to implement but I would expect that internal RTI time is reset to the timeinstance of saving after the FederateRestoreAchieved callback occurs.

Could you please help me with finding a solution to this problem?

Joris Steneker <joris>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by joris (Submitted the item)
  • -email is unavailable- added by joris
  •  

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-05-23 joris Carbon-Copy- Added joris

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code