bugCERTI - Bugs: bug #1795, Enable Time Constrained/Regulation...

 
 

bug #1795: Enable Time Constrained/Regulation callbacks not used

Submitter:  Benoit BREHOLEE <breholee>
Submitted:  Sun 24 Nov 2002 10:07:27 PM UTC
   
 
Category:  CERTI Severity:  * 3 - Normal
Item Group:  HLA compliance error Status:  Ready For Test
Privacy:  Public Assigned to:  approx
Open/Closed:  Closed Release:  * CVS
Reproducibility:  Every Time Fixed Release:  * 3.4.1
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 15 Apr 2009 06:45:17 AM UTC, comment #35: 

this problem depends probably on bug #25497 .

Christian Stenzel <approx>
Group Member
Wed 16 Jul 2008 08:21:04 AM UTC, comment #34: 

Please find attached my test project



(file #16125)

Michael Raab <michaelraab>
Wed 16 Jul 2008 08:05:33 AM UTC, comment #33: 


> I will to provide you a test app, but i will be in vs2005.net.
> OK for you?


I would rather like a "system agnostic" test app but
I may try to make one out of you vs2005.net one
if it is small enough.

> by the way, could you provide the full HLA1.3 specification?


No unfortunately I cannot, HLA specs is not free,
I don't know if one can find HLA1.3 specs but
one could buy IEEE-1516 from IEEE
http://ieeexplore.ieee.org/xpl/standards.jsp?findtitle=1516&letter=1516&imageField.x=0&imageField.y=0&opentree=on

Eric NOULARD <erk>
Group administrator
Wed 16 Jul 2008 07:45:59 AM UTC, comment #32: 

Hi Eric,

the enablingTimeRegulation procedure in my application looks like this:

void TimeManagement::enableTimeRegulation( double theFederateTime, double theLookahead )
{
// convert times...
RTIfedTime fedtime(theFederateTime);
RTIfedTime lookahead(theLookahead);

HLAManagement::GetRTIAmb()->enableTimeRegulation(fedtime, lookahead);

TimeManagement::_regulationRequestPending = true;

while(TimeManagement::_regulationRequestPending)
{
HLAManagement::tick(0.1, 1.0);
}
}

where the timeRegulationEnabled callbacks causes a local update of simulation time and of course unsetting the flag regulationRequestPending.

QueryFederateTime tells me that the current fed time is zero (as i would expect).

I will to provide you a test app, but i will be in vs2005.net.
OK for you?

By the way, could you provide the full HLA1.3 specification?

Michael


Michael Raab <michaelraab>
Wed 16 Jul 2008 07:33:12 AM UTC, comment #31: 

Michael,

In HLA 1.3 §8.2 (Enable Time Regulation)
on can read:
_Because the invocation of this service may require the RTI to advance the invoking federate’s logical time, this service
has an additional meaning for time-constrained federates. Since the advancing logical time for a time-constrained fed-
erate is synonymous with a guarantee that all TSO messages with time stamps less than the new logical time have been
delivered, the invocation of this service shall be considered an implicit Time Advance Request Available service invo-
cation. The subsequent invocation of Time Regulation Enabled † shall be considered an implicit Time Advance Grant
† service invocation._

So your mentioned  procedure

> create fed
> join fed
> enable asyn delivery
> enable time regulation (0.0, lookahead)
> enable time constrained


 is OK but... after that since EnableTimeRegulation
may be considered as a TAR and TimeRegulationEnabled
callback as TAG you may have already advance in time.

Would you try to QueryFederateTime before trying TAR?

As noted by Christian, this could be a buggy behavior
so if you could provided us with a small test program
which exhibit the problem we will be able to track it
down more easily.






Eric NOULARD <erk>
Group administrator
Wed 16 Jul 2008 05:41:41 AM UTC, comment #30: 

Good morning,

i just tried to use NER instead of TAR, but it comes to the same results. Timesteps with a minimum length of lookahead are possible, shorter steps cause an InvalidTimeException.

Michael

Michael Raab <michaelraab>
Tue 15 Jul 2008 04:44:09 PM UTC, comment #29: 

One last note:

Perhaps it depends also on the used time advance mechanism.

Using Time Advance Request (TAR) can be associated as time stepped
simulation. So here the described behaviour can make sense (no time advance to a value within the interval [tcurrent
tcurrent+lh]). In generral the next time step should have a timestamp with a value of tcurrent + lh.

Using Next Event Request (NER) is associated with event driven
simulations. Here time advances have no fixed increment and
intermediate time advance step should be allowed.

Christian Stenzel <approx>
Group Member
Tue 15 Jul 2008 02:45:13 PM UTC, comment #28: 

Me again,

at some time ago I tried to explain
some conservative sync algorithms in a seminar
at our university. The talk is in German. So
probably only Michael can use it really.

Look at pages 65(51)... there one can find some
"animated" slides.

Since CERTI implements a nullmessage algorithm
it could be useful for you.

Here's the link:
http://www.mb.hs-wismar.de/~stenzel/talks/20070710_vortrag_distSim.pdf

Christian Stenzel <approx>
Group Member
Tue 15 Jul 2008 02:35:15 PM UTC, comment #27: 

I believe that you're right.

Lookahead is used to guarantee other LPs that I do not
generate events with a time stamp less than MyTNow + LH.

Let's say the Lookahead value lh=10. MyTNow is 0.

Then there can be an local event with a timestamp of let's
say 5. Now we have to advance to myTNow = 5 and execute that event.
While execution that event generates a remote event
with a timestamp of myTNow+Lh (5+10=15, minimum time stamp for
remote events) and a local event at time 7.

So now need to advance to time 7 to execute that event.

So I suppose that you're right. Time advancing
between the interval [myTnow myTnow+LH] have to be possible.

I think that Eric and Pierre are experts here.

Perhaps you can write a small test federate to demonstrate the
problem. So we can investigate that problem in more detail.

Christian Stenzel <approx>
Group Member
Tue 15 Jul 2008 02:04:07 PM UTC, comment #26: 

Thats the behavior that i've expected ( 2. ).

But to me there seems to be another problem:

i do the following:

create fed
join fed
enable asyn delivery
enable time regulation (0.0, lookahead)
enable time constrained

If i try to advance simulation time and choose a timestamp that is lesser than is between currentTime and currentTime + lookahead then i get an InvalidTimeException.

To lookahead specifies that i cannot generate events (attribute update, interactions, ...) for timestamps that are lesser that currentTime + lookahead. But time advancement to a point between currentTime and currentTime+lookahead should be possible and is possible in other RTI implementations (for example dmso).

What do you think?

Michael


Michael Raab <michaelraab>
Tue 15 Jul 2008 01:46:57 PM UTC, comment #25: 

One more note:
As I know, at time CERTI is not multithreaded. That's why 1) can
not work. The LRC needs time to transmit the callbacks.
This time is provided through the invocation of tick. So
only your second method wwork with CERTI.

Christian Stenzel <approx>
Group Member
Tue 15 Jul 2008 01:43:24 PM UTC, comment #24: 

No prob, do the following

rtiamb.enableTimeConstrained()
rtiamb.enableAsynchronousDelivery()

then tick until you get the callback
timeConstrainedEnabled()


Christian Stenzel <approx>
Group Member
Tue 15 Jul 2008 01:40:26 PM UTC, comment #23: 

Hi,

thx for your quick reply. By the way i used the 3.3.0 installer...

Just to get this correct, if i enable asynchronous delivery, when do i get callbacks?

1.) whenever they are there or
2.) whenever i call tick()?

Michael

Michael Raab <michaelraab>
Tue 15 Jul 2008 01:29:41 PM UTC, comment #22: 

Hi Micheal,

the reason for taht behaviour is described somewhere below
in this thread.

Probably you have no fresh cvs version. Please checkout
a new one.

If you use the current version available in the download section
you can do the following:

After enabling time constrained with
enableTimeConstrained() do a
enableAsynchronousDelivery().

After that you will get th ecallback.

The background is the following:
In the current cvs version the callbacks
timeCOnstrainedEnabled and timeRegulationEnabled
are treated as commands. The versions before treat
these callbacks as ro messages.

And as a rule time constrained federates have to
enable their asynchronous delivery switch to
receive ro messages outside a time advance request.

But as I said we noew treat that callbacls as
commands.

So you should get it. For an example see the federate
test_TRTCCallbacks in the HLA_TestsSuite foler.

So long,
Christian


Christian Stenzel <approx>
Group Member
Tue 15 Jul 2008 01:16:12 PM UTC, comment #21: 

Hi,

what's the current status of the enableTimeRegulation, enableTimeConstrained discussion?

I tried to create a simple federate that is both regulating and constrained. The enableTimeRegulation call gives me the TRE feedback, but for enableTimeConstrained i receive nothing!
Simply calling enableTimeConstrained without enableTimeRegulation before has the some result!

thx,
Michael

Michael Raab <michaelraab>
Fri 11 Jul 2008 06:59:25 PM UTC, comment #20: 


> Until now U had no success with the new dtest version.


Pretty true.
Lack of time means lacks of testing,
which is just a shame for a test framework :=)

I will certainly make a dtest 0.5.1 which fix
the install issues with proper dependency checking
at runtime.

> I will make a new try at home. Which python version is
> required, I use 2.4. Should I upgrade to 2.5?


Python 2.4 should be OK.
You "only" require paramiko 1.7.x which in turns
requires pycrypto.


Eric NOULARD <erk>
Group administrator
Fri 11 Jul 2008 03:00:42 PM UTC, comment #19: 

Just committed the small changes. Note I also
removed enableAsyncDelivery from the test_TRTRTCCallbacks
federate because it is no longer needed. Since TCE is now
a command it is passed independently of any states to the
federate.

Christian Stenzel <approx>
Group Member
Fri 11 Jul 2008 02:46:29 PM UTC, comment #18: 

Hi Eric,

now it works! I've made a fresh cvs checkout of dtest,
after that a "full installation" with all externals
and set my envvar PYTHONPATH to the dtest dir.

After that make test works fine for me.

With the dtest-0.5 file from from the download area
I had no luck

Christian Stenzel <approx>
Group Member
Fri 11 Jul 2008 02:36:25 PM UTC, comment #17: 

Until now U had no success with the new dtest version.

I will make a new try at home. Which python version is
required, I use 2.4. Should I upgrade to 2.5?

Christian Stenzel <approx>
Group Member
Fri 11 Jul 2008 10:18:31 AM UTC, comment #16: 

You should update your DTest.
I will add version check in order to avoid this
situation and throw a meaning full message instead
of a bare stacktrace.

The script is using dtest-0.5 and up
you local dtest install should predate dtest-0.5 (June, 23 2008)
you may cvs update dtest if it is a cvs tree
or take dtest-0.5 archive:
http://download.savannah.gnu.org/releases/tsp/dtest/dtest-0.5.tar.gz

Note there is ongoing bug for dtest usage:
https://savannah.nongnu.org/bugs/?23721
https://savannah.nongnu.org/bugs/?23720

but you shouldn't face those since you already runned dtest
before.

Eric NOULARD <erk>
Group administrator
Fri 11 Jul 2008 10:04:13 AM UTC, comment #15: 

Hi Eric,

I've a problem with the auto test Suite.

make test fails. A single test to. It produces the
following output when invoking e.g.

>./dtest_test_TRTCCallbacks.py


Traceback (most recent call last):
  File "./dtest_test_TRTCCallbacks.py", line 44, in ?
    rtig_param = dtest.Utils.getUserHostPath("rtig")
AttributeError: 'module' object has no attribute 'Utils'

dtest-autotest works, also dtest-sshtest. I set the env var
PYTHONPATH to my dtest folder.





Christian Stenzel <approx>
Group Member
Fri 11 Jul 2008 09:00:33 AM UTC, comment #14: 

My opinion is that you may apply the patch
as soon as the corresponding
HLA_TestsSuite/test_TRTCCallbacks passes OK.

Eric NOULARD <erk>
Group administrator
Fri 11 Jul 2008 08:51:29 AM UTC, comment #13: 

If there are no objections I would apply a patch.

Christian Stenzel <approx>
Group Member
Fri 11 Jul 2008 08:49:50 AM UTC, comment #12: 

I reopened this bug, because of the discussions in
the dev mailing list.

Eric describes the problem:
http://lists.nongnu.org/archive/html/certi-devel/2008-06/msg00024.html
In short: To get the callback Time Constrained Enabled one have to
enable AsynchronousDelivery before ticking outside a timeAdvancerequest (because the federate is time constrained).

After that some others verified the current implementation of CERTI
with other RITs.
http://lists.nongnu.org/archive/html/certi-devel/2008-06/msg00027.html
Here we get the same runtime behaviour like RTI-NG.

But Pierre give the advise to treat the callbacks TRE/TCE as
commands, not as RO messages.
http://lists.nongnu.org/archive/html/certi-devel/2008-07/msg00030.html
So we can avoid the strange behaviour.

Christian Stenzel <approx>
Group Member
Mon 12 May 2008 12:19:52 PM UTC, comment #11: 

Ok then,
Have a good time with your family.
I've checked-in the patch.
Concerning FIFO/TSO/Command queue
I will check with Jean-Yves and Pierre
but I think command was a kind of "special FIFO"
for "command" like requestPause, requestFederationSaveXXX,
etc...

I keep the callback inserted in FIFO.

Eric NOULARD <erk>
Group administrator
Sun 11 May 2008 01:56:44 PM UTC, comment #10: 

Hi Eric,

many thanks for your work. I have taken some free
days with my family, so don't worry to apply the
patch by yourself.

I will study your changes at the end of the next week
in detail.

A short question, the code snippet below (from the attached
patch) inserts the callbacks in the FIFO queue. Here I was
unsure, because there is also a command queue.


+++ RTIA/RTIA_network.cc 10 May 2008 08:15:49 -0000
@@ -326,6 +326,17 @@
         queues->insertFifoMessage(msg);
         break ;
 
+      case NetworkMessage::TIME_REGULATION_ENABLED:
+      D.Out(pdTrace, "Receiving Message from RTIG, "
+      " type TimeRegulationEnabled.");
+      queues->insertFifoMessage(msg);
+      break ;
+      case NetworkMessage::TIME_CONSTRAINED_ENABLED:
+      D.Out(pdTrace, "Receiving Message from RTIG, "
+      " type TimeConstrainedEnabled.");
+      queues->insertFifoMessage(msg);
+      break;




Christian Stenzel <approx>
Group Member
Sat 10 May 2008 08:18:20 AM UTC, comment #9: 

Find attached an updated patch
which should be just like yours but which
is synchronized with current CVS.

If you are OK with it you may do the commit yourself.


(file #15652)

Eric NOULARD <erk>
Group administrator
Fri 09 May 2008 08:47:43 PM UTC, comment #8: 

As I told you in another message
 I made some change in NetworkMessage.
I'll try to sync your patch with the current tree,
unless you are wanting to do it?

(shouldn't be a lot of work I may try tomorrow).


Eric NOULARD <erk>
Group administrator
Fri 09 May 2008 07:06:56 AM UTC, comment #7: 

Hello Eric,

thanks for your hints. Hopefully I will remember at the next time :).


Christian Stenzel <approx>
Group Member
Thu 08 May 2008 12:45:14 PM UTC, comment #6: 

Hi Christian,

Nice patch, I'm not finished reviewing it but
concerning added NetworkMessage:


NM_Time_Regulation_Enabled::NM_Time_Regulation_Enabled() {
        this->name = "TIME_REGULATION_ENABLED";
        this->type = NetworkMessage::TIME_REGULATION_ENABLED;
        isDated =true;
}


you should not set isDated to true in the constructor.
the "isDated" field will be automatically set
whenever the setter
NetworkMessage::setDate(double date) is called.

this way it is easy to implement timestamped or not timestamped
variant of some network message.
If the sender call setDate before sending the message
then message isDated.

NetworkMessage::serialize
NetworkMessage::deserialize

will automatically handle timestamped or not timestamped message.

I may switch isDated to be a private field, this way a
daughter class won't be able to set it.

Concerning RTIG or local RTIA handling I think
RTIG is the conservative solution, but off course local RTIA
callback would be more efficient (avoid RTIA<->RTIG roudnd-trip)

I think we should go on with the current idea of RTIG
callback (which in this case is just a acknowledge)
unless we imagine another scheme with ensured safety property.

Currently if the NM_Set_Time_Constrained was lost
Federate may consider to be Constrained but RTIG won't
handle it this way.

I had a conflict in RTIA_network.cc because your local
tree may not be up-to-date (there have been a lot of check-in
last days)

I'll work on your patch keep you posted.


Eric NOULARD <erk>
Group administrator
Thu 08 May 2008 06:59:47 AM UTC, comment #5: 

The patch below generates the callbacks TRE resp. TCE within the
rtig process. Another possible solution would be to send the
callbacks immediately in the rtia process.

I'm not sure which solution would be the best.

Christian Stenzel <approx>
Group Member
Wed 07 May 2008 04:19:04 PM UTC, comment #4: 

Hi,

the attached patch file contains a possible solution.

I've tested with test_TRTCCallbacks from the HLA_TestsSuite folder.



(file #15632)

Christian Stenzel <approx>
Group Member
Fri 02 May 2008 06:43:45 PM UTC, comment #3: 

Forgot to assign the bug to you.
Now done

Eric NOULARD <erk>
Group administrator
Fri 02 May 2008 06:41:41 PM UTC, comment #2: 

Hi Christian,
Go ahead.
I really don't know why this bug/feature missing
was dormant for so long.

Eric NOULARD <erk>
Group administrator
Fri 02 May 2008 04:35:37 PM UTC, comment #1: 

I would like to do it.

Is there a special reason, why this bug was so long untouched?



Christian Stenzel <approx>
Group Member
Sun 24 Nov 2002 10:07:27 PM UTC, original submission:  

Enable Time Contrained/Regulation services have HLA 1.3 API but HLA 1.0 behaviour: federate has to time advance until the request is successful, and the callbacks are not used.

Benoit BREHOLEE <breholee>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #16125:  TestCERTIreduced.zip added by michaelraab (233KiB - application/zip)
file #15652:  TRTCCallbacks-bug1795-erk1.patch added by erk (17KiB - text/x-diff - Updated patch against current CVS tree)
file #15632:  TRTCCallbacks.patch1 added by approx (17KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by michaelraab (Posted a comment)
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by approx (Posted a comment)
  •  

    Follow 21 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-10-18 erk Open/ClosedOpen Closed
        Fixed Release3.3.0 3.4.1
    2008-07-16 michaelraab Attached File- Added TestCERTIreduced.zip, #16125
    2008-07-11 approx StatusIn Progress Ready For Test
    2008-07-11 approx StatusFixed In Progress
        Open/ClosedClosed Open
    2008-07-02 erk StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseCVS 3.3.0
    2008-05-12 erk StatusIn Progress Ready For Test
        Fixed ReleaseNextRelease CVS
    2008-05-10 erk Attached File- Added TRTCCallbacks-bug1795-erk1.patch, #15652
    2008-05-07 approx StatusNone In Progress
    2008-05-07 approx Attached File- Added TRTCCallbacks.patch1, #15632
    2008-05-02 erk Assigned toNone approx
    2008-05-02 approx Fixed ReleaseNone NextRelease
    2008-05-02 approx ReleaseNone CVS
    2005-12-16 breholee SummaryEnable Time Contrained/Regulation callbacks not used Enable Time Constrained/Regulation callbacks not used
    2005-02-23 breholee Severity4 - Important 3 - Normal
    2004-05-06 breholee Severity3,5 4 - Important
    2003-10-27 breholee Severity3 - Normal None

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code