|
From: | Eric Noulard |
Subject: | Re: [certi-dev] TAG and transient message |
Date: | Fri, 28 Aug 2015 09:36:47 +0200 |
Le 27/08/2015 18:24, Eric Noulard a écrit :
Nope sorry, I did not find the time for that.I may try tomorrow.
Pierre did you investigate the issue in the code?
Hello,
I have illustrated the problem with the Interactive Federate and the help from David,
I will send that as soon as possible.
Probably, there is a mistake in our implementation.
Some examples are working well and a characterization of a faulty/working program is not done.
Our optimization is based on the messages that are passing through the RTIG process,
but we have implemented some parts of the optimization in the RTIA processes ...
(a distributed implementation at the place of a centralized implementation ...)
Need some time to detail that.
Eric
2015-07-27 20:43 GMT+02:00 David Come <address@hidden>:
Hi.
Any update on that ?
Thanks,
David.
Le 01/07/2015 06:50, Pierre Siron a écrit :
Hello David,
I have reproduced this behaviour with the interactive federate
(just s/uav/si/).
A RTI B
NER(100)
<--------------
SI(1)
-------------->
NER (100)
-------------->
RI(1)
--------------->
TAG(1)
--------------->
NER(100)
<---------------
TAG(100)
--------------->
I suppose that this is ok until the last TAG(100).
With the NER(100) of the federate A,
there is a NULL MESSAGE PRIME sent with 100.
This NULL MESSAGE PRIME shoud accelerate the time advancement
of B one time, not many times.
This looks like a lack of variable reinitialization
and I (we) have to review the CERTI code here.
A bientôt,
Pierre
Le 30/06/2015 21:05, David Come a écrit :
Hello.
Please find attached two quick and dirty C++ applications that reproduce the same behaviour.
They are a direct rip off of the Interactive_federate from the application folder. The only important parts are the PubSub, send methods and the mains' loops.
I put a schema describing the simulation architecture.
Bulding and using :
unzip source.zip
mkdir bin
cd bin
cmake ../src
make
./A_loop Federate_Name Absolute_Path_To_Fed_file
./B_loop Federate_Name Absolute_Path_To_Fed_file
I created a poor man's synchronization using getchar, so you need to press enter in both federates after they have been started.
That simulation exhibits different behaviors if it is linked and run with CERTI using NULL Prime messages or not.That was the case for the first logs I send. A single process with 2 threads, each being a Federate. This lead to inconsistent (and unusable) log files.
In order to avoid java thread mix in the log may be you can configure log4j to timestamp your log entry.I'm just running 2 applications.
Yes Ok, but I was thinking more of a multi-threaded Java application calling jcerti simultaneously from
different path (in the same application). I'm not sure jcerti is ready for that so I was wondering whether
the trace of A federate could me intermixed or not.
That is why I backed to using two different processes.
David.
--
CERTI-Devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/certi-devel
--
Eric
--
CERTI-Devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/certi-devel
[Prev in Thread] | Current Thread | [Next in Thread] |