mratc-developers — Project Developers

[Mratc-developers] Compute time for Vincenty equations

[Michael R. <ht...@us...>]

I coded Inverse Vincenty equations in both C and Perl to
compare.  Our system is going to be spending a lot of time on
these equations, so we probably want to optimize around them.

The C version could do 35328 Inverse Vincentys per second.  Perl
could do 5091 Inverse Vincentys per second.  Going by that, C is
seven times faster than Perl in Inverse Vincentys--a performance
improvement worth taking advantage of.  Perl was more
cooperative than C during coding.  However, to realize the
performance improvements, it is worth taking a little beating
during coding.

Let me try and attach the C and Perl source files, see if they
go through.

--Mike

Re: [Mratc-developers] [my status]

[Michael R. <ht...@us...>]

----- Original Message -----
From: "Aquila Deus" <aqu...@ya...>

> Hey! What if we don't deal with the http communcation part? I
mean, just do
> what ATC controllers exactly do (they don't need to worry
about the network
> traffic issue, right?)
>
> We define our own interface to get flights/radar info and send
back messages to
> flights. No need to use network/http/etc. The flights/radar
emulations can be
> done all together, in one program.
>
> Comment?

I think network communication is an important part of
simulation.  One benefit from incorporating network
communication is we can have flight simulations running on
machines all over the world, to better simulate a real load.

During development, we could maybe have a version of the
software that does not incorporate network communications and
later migrate to a version that does.  Maybe function calls in
the preliminary version can be turned into http
requests/responses in later versions.

If you are going to code ATC, radar, and flights all in one
program, maybe classify functions into categories (functions
called by the ATC, radar, flights, or a combination of the
three).  Then, when we want to split up the program later, we
can just copy the appropriate functions into the various
programs.

--Mike

Re: [Mratc-developers] [my status]

[<aqu...@ya...>]

 --- Michael Ross <iw...@co...> wrote: 
> I've been thinking that over for years.  Haven't come up with an
> answer yet.  The biggest problem I can see at the moment is the
> geodetic equations used to compute distances and bearings
> between planes.  Those equations can be found at
> http://www.ngs.noaa.gov/PUBS_LIB/inverse.pdf
> They are not as simple as a Pythagorean Theorem or basic
> trigonometry.

Hey! What if we don't deal with the http communcation part? I mean, just do
what ATC controllers exactly do (they don't need to worry about the network
traffic issue, right?)

We define our own interface to get flights/radar info and send back messages to
flights. No need to use network/http/etc. The flights/radar emulations can be
done all together, in one program.

Comment?

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] [my status]

[<aqu...@ya...>]

 --- Michael Ross <iw...@co...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> > > Currently, air traffic controllers are performing collision
> > > avoidance with their eyes.  They look at their radar screen
> and
> > > tell flights to adjust their course if they are headed for a
> > > collision.  A human being has a certain limit to the number
> of
> > > flights he or she can safely process at one time.  Computers
> can
> > > process information faster and more accurately than humans.
> >
> > Ummmm... If that's all, things would be very simple :)
> 
> I am not thinking this project is very complicated.  If it were
> more complicated, I might not be so interested in taking it on.
> 
> > But why don't they just replace useless human beings with
> computers? What's the
> > problem they face??
> 
> I've been thinking that over for years.  Haven't come up with an
> answer yet.  The biggest problem I can see at the moment is the
> geodetic equations used to compute distances and bearings
> between planes.  Those equations can be found at
> http://www.ngs.noaa.gov/PUBS_LIB/inverse.pdf
> They are not as simple as a Pythagorean Theorem or basic
> trigonometry.

OK.

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] [my status]

[Michael R. <iw...@co...>]

----- Original Message -----
From: "Aquila Deus" <aqu...@ya...>

> > Currently, air traffic controllers are performing collision
> > avoidance with their eyes.  They look at their radar screen
and
> > tell flights to adjust their course if they are headed for a
> > collision.  A human being has a certain limit to the number
of
> > flights he or she can safely process at one time.  Computers
can
> > process information faster and more accurately than humans.
>
> Ummmm... If that's all, things would be very simple :)

I am not thinking this project is very complicated.  If it were
more complicated, I might not be so interested in taking it on.

> But why don't they just replace useless human beings with
computers? What's the
> problem they face??

I've been thinking that over for years.  Haven't come up with an
answer yet.  The biggest problem I can see at the moment is the
geodetic equations used to compute distances and bearings
between planes.  Those equations can be found at
http://www.ngs.noaa.gov/PUBS_LIB/inverse.pdf
They are not as simple as a Pythagorean Theorem or basic
trigonometry.

--Mike

Re: [Mratc-developers] [my status]

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> > > If obstacles are in the way, we guide the flights around
> them,
> > > but otherwise let the flights choose their own path.  We are
> in
> > > charge of short-term (within the next minute or so)
> navigation;
> > > the flights are in charge of long-term navigation.
> >
> > But if so, the flights may not need the ATC. They should be
> able to detect
> > short-term problems, just like fighters.
> 
> Maybe.  That is an excellent way to distribute processing.
> However, could a flight ever be between a rock and a hard place
> and by itself find no safe route through, while an ATC, seeing
> the big picture and following a ruleset, could find a safe route
> (by moving other planes out of the way, for example)?
> 
> The industry is experimenting with free flight ATC, where each
> flight is in charge of its own collision avoidance.  They are
> having a hard time implementing something that reliably does the
> job.
> 
> Think of this.  What if flight A and flight B were approching
> point X, both flights due to arrive at point X at the same time?
> Which flight should cede right of way to the other?  I suppose a
> ruleset could be implemented like the flight on the right yields
> to the flight on the left.  But with this ruleset comes a
> problem.  If the flight on the right is supposed to make a
> course adjustment, but cannot, because it is up against
> restricted airspace, the flight on the left should make a course
> adjustment.  But how can the flight on the left know the flight
> on the right cannot make an adjustment?  Centralized ATC could
> solve this problem.
> 
> What if five flights were approaching from five different
> directions and due to arrive at point X at the same time?  How
> do they get out of that jam?  Separating different headings into
> different altitudes might help with this problem.
> 
> Flights cannot be flying around in total randomness.  There
> needs to be some kind of order established for them.  For
> example, currently, they have highways in the sky that flights
> follow.  I propose different headings should fly at different
> altitudes.  Can you imagine the darting back and forth a flight
> would have to do to avoid flights approaching from every
> direction?  Darting back and forth is not something commercial
> airliners were designed to do.  Passengers probably would not
> care too much for it, either.
> 
> If different headings are separated into different altitudes,
> what happens when a flight wants to change its heading/altitude?
> Will its radar be able to tell if the course is clear at the new
> altitude and heading?
> 
> > I have never heard two close fighters hit each other.
> 
> There are not usually thousands of fighters in the sky at the
> same time.  They usually go on sorties, or predefined flights,
> or missions.  As the sorties are laid out, I'm sure they take
> into consideration conflct or integration with other sorties.
> 
> Pilots cannot reliably perform collision avoidance with their
> eyes because the rate of closure at mach 0.85 is too high.
> Also, bad weather or darkness makes this difficult.
> 
> Currently, air traffic controllers are performing collision
> avoidance with their eyes.  They look at their radar screen and
> tell flights to adjust their course if they are headed for a
> collision.  A human being has a certain limit to the number of
> flights he or she can safely process at one time.  Computers can
> process information faster and more accurately than humans.

Ummmm... If that's all, things would be very simple :)

But why don't they just replace useless human beings with computers? What's the
problem they face??

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] [my status]

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> > I think the current ATC works in this way:
> >
> > - All available courses are already defined (could be added or
> removed though)
> > - Generally the courses are not used or affected by any
> unmanaged flights.
> 
> If an unmanaged flight gets in the way, the managed flight is
> directed around it, is my guess.

How about shoot it down? :)

I think the management center does not allow this at all.

> 
> > - The flight must register the courses it wants and the range
> of time it will
> > need to go though, before it flys.
> > - If it wants to change the course when flying, it has to
> request the change
> > first.
> >
> > * Some flights may have higher priority to obtain courses they
> want.
> > * The ATC doesn't check collision continually, because
> potential collisions
> > should be avoided when the ATC handles course requests.
> 
> Collisions are routinely a possibility (and need to be
> constantly watched for) with the current system in the following
> ways:
> 
> - faster planes overtaking slower planes on the designated
> highways in the sky
> - planes coming together on different highways in the sky at
> junctions where the highways meet

Ummm... I think all flights have to fly through the courses during the given
range of time. They simply cannot fly too fast or too slow, or come to the
junctions too early or too late. And they have better to register the speed
too. In this way everythings will run smoothly.

> 
> > * The ATC needs to deal with exceptions: weather, unexpected
> obstacles, and
> > flights which can't fly though their courses on time, etc.
> 
> --Mike
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Mratc-developers mailing list
> Mra...@li...
> https://lists.sourceforge.net/lists/listinfo/mratc-developers
>  

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] [my status]

[Michael R. <ht...@us...>]

----- Original Message -----
From: "Aquila Deus" <aqu...@ya...>

> > If obstacles are in the way, we guide the flights around
them,
> > but otherwise let the flights choose their own path.  We are
in
> > charge of short-term (within the next minute or so)
navigation;
> > the flights are in charge of long-term navigation.
>
> But if so, the flights may not need the ATC. They should be
able to detect
> short-term problems, just like fighters.

Maybe.  That is an excellent way to distribute processing.
However, could a flight ever be between a rock and a hard place
and by itself find no safe route through, while an ATC, seeing
the big picture and following a ruleset, could find a safe route
(by moving other planes out of the way, for example)?

The industry is experimenting with free flight ATC, where each
flight is in charge of its own collision avoidance.  They are
having a hard time implementing something that reliably does the
job.

Think of this.  What if flight A and flight B were approching
point X, both flights due to arrive at point X at the same time?
Which flight should cede right of way to the other?  I suppose a
ruleset could be implemented like the flight on the right yields
to the flight on the left.  But with this ruleset comes a
problem.  If the flight on the right is supposed to make a
course adjustment, but cannot, because it is up against
restricted airspace, the flight on the left should make a course
adjustment.  But how can the flight on the left know the flight
on the right cannot make an adjustment?  Centralized ATC could
solve this problem.

What if five flights were approaching from five different
directions and due to arrive at point X at the same time?  How
do they get out of that jam?  Separating different headings into
different altitudes might help with this problem.

Flights cannot be flying around in total randomness.  There
needs to be some kind of order established for them.  For
example, currently, they have highways in the sky that flights
follow.  I propose different headings should fly at different
altitudes.  Can you imagine the darting back and forth a flight
would have to do to avoid flights approaching from every
direction?  Darting back and forth is not something commercial
airliners were designed to do.  Passengers probably would not
care too much for it, either.

If different headings are separated into different altitudes,
what happens when a flight wants to change its heading/altitude?
Will its radar be able to tell if the course is clear at the new
altitude and heading?

> I have never heard two close fighters hit each other.

There are not usually thousands of fighters in the sky at the
same time.  They usually go on sorties, or predefined flights,
or missions.  As the sorties are laid out, I'm sure they take
into consideration conflct or integration with other sorties.

Pilots cannot reliably perform collision avoidance with their
eyes because the rate of closure at mach 0.85 is too high.
Also, bad weather or darkness makes this difficult.

Currently, air traffic controllers are performing collision
avoidance with their eyes.  They look at their radar screen and
tell flights to adjust their course if they are headed for a
collision.  A human being has a certain limit to the number of
flights he or she can safely process at one time.  Computers can
process information faster and more accurately than humans.

--Mike

Re: [Mratc-developers] [my status]

[Michael R. <ht...@us...>]

----- Original Message -----
From: "Aquila Deus" <aqu...@ya...>

> I think the current ATC works in this way:
>
> - All available courses are already defined (could be added or
removed though)
> - Generally the courses are not used or affected by any
unmanaged flights.

If an unmanaged flight gets in the way, the managed flight is
directed around it, is my guess.

> - The flight must register the courses it wants and the range
of time it will
> need to go though, before it flys.
> - If it wants to change the course when flying, it has to
request the change
> first.
>
> * Some flights may have higher priority to obtain courses they
want.
> * The ATC doesn't check collision continually, because
potential collisions
> should be avoided when the ATC handles course requests.

Collisions are routinely a possibility (and need to be
constantly watched for) with the current system in the following
ways:

- faster planes overtaking slower planes on the designated
highways in the sky
- planes coming together on different highways in the sky at
junctions where the highways meet

> * The ATC needs to deal with exceptions: weather, unexpected
obstacles, and
> flights which can't fly though their courses on time, etc.

--Mike

Re: [Mratc-developers] [my status]

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> > Ummm... The problem is: The real radar system is not going to
> be
> > developed by us. So we need to know what interface the
> manufacturer
> > will provide. Is this possible, now?
> 
> Why can't we define the interface now (http, or whatever works
> best for us)?  Since we are coming first, we can define things
> how we want them.  If the FCC decides to implement our system,
> radar vendors will comply with our interface specifications.
> The interface needs to be doable for the radar vendors, but we
> do not need to bend over backwards (go out of our way) to build
> around the radar vendors.

OK!

> 
> > > > ATC: the only thing we can be sure that it has only one
> source
> > > of input and
> > > > output. But that's good enough for us to start working on
> :)
> > >
> > > What do you mean by "one source of input and output?"
> >
> > The flight management system. The ATC retrieve and send
> everything via it (and
> > only via it). By this method we may make the development of
> ATC easier, because
> > things in the flight management system such as communicating
> to radar or
> > flights are uncertain.
> 
> We will have to define an interface for simulation over the
> Internet, will we not?  As well as a production interface?  If
> you want to create your version of the flight management system
> (FMS) using a single, undefined input and output, that's fine
> with me.  Maybe it will work better than my idea of defined http
> interfaces for communication.

Ah no! It's not about http. My idea is just to seperate the ATC and the outside
environment, to make the development of ATC easier. I'm sure about what
communication protocol to use between ATC and FMS.

> 
> > One question: If our ATC only helps flights to avoid collision
> and let them
> > decide what course they follow (and there is no pre-defined
> course), we may not
> > need to manage the course change at all.
> 
> They need to ask permission for a course change so our FMS can
> make sure their desired course change will not put them in
> harm's way.  Once the coast is clear, we can give instruction to
> the flight to make the course change.
> 
> > Besides, if the flights decide the
> > course by itself, it may hit flights or objects which are not
> managed by our
> > ATC (we can know this from radar though), and the possibility
> may be bigger
> > than hitting managed flights. Are you sure to let the flights
> decide the course
> > by themselved? Isn't this too different from current ATC?
> 
> If obstacles are in the way, we guide the flights around them,
> but otherwise let the flights choose their own path.  We are in
> charge of short-term (within the next minute or so) navigation;
> the flights are in charge of long-term navigation.

But if so, the flights may not need the ATC. They should be able to detect
short-term problems, just like fighters... I have never heard two close
fighters hit each other.

> 
> > BTW I have a good news for you: I won't touch java anymore,
> until I get a fast
> > computer... It's too terrible!
> 
> LOL


=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] [my status]

[<aqu...@ya...>]

--- Aquila Deus <aqu...@ya...> wrote: 
> One question: If our ATC only helps flights to avoid collision and let them
> decide what course they follow (and there is no pre-defined course), we may
> not
> need to manage the course change at all. Besides, if the flights decide the
> course by itself, it may hit flights or objects which are not managed by our
> ATC (we can know this from radar though), and the possibility may be bigger
> than hitting managed flights. Are you sure to let the flights decide the
> course
> by themselved? Isn't this too different from current ATC?

I think the current ATC works in this way:

- All available courses are already defined (could be added or removed though)
- Generally the courses are not used or affected by any unmanaged flights.
- The flight must register the courses it wants and the range of time it will
need to go though, before it flys.
- If it wants to change the course when flying, it has to request the change
first.

* Some flights may have higher priority to obtain courses they want.
* The ATC doesn't check collision continually, because potential collisions
should be avoided when the ATC handles course requests.
* The ATC needs to deal with exceptions: weather, unexpected obstacles, and
flights which can't fly though their courses on time, etc.

Do I miss anything?

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] [my status]

[Michael R. <ht...@us...>]

----- Original Message -----
From: "Aquila Deus" <aqu...@ya...>

> Ummm... The problem is: The real radar system is not going to
be
> developed by us. So we need to know what interface the
manufacturer
> will provide. Is this possible, now?

Why can't we define the interface now (http, or whatever works
best for us)?  Since we are coming first, we can define things
how we want them.  If the FCC decides to implement our system,
radar vendors will comply with our interface specifications.
The interface needs to be doable for the radar vendors, but we
do not need to bend over backwards (go out of our way) to build
around the radar vendors.

> > > ATC: the only thing we can be sure that it has only one
source
> > of input and
> > > output. But that's good enough for us to start working on
:)
> >
> > What do you mean by "one source of input and output?"
>
> The flight management system. The ATC retrieve and send
everything via it (and
> only via it). By this method we may make the development of
ATC easier, because
> things in the flight management system such as communicating
to radar or
> flights are uncertain.

We will have to define an interface for simulation over the
Internet, will we not?  As well as a production interface?  If
you want to create your version of the flight management system
(FMS) using a single, undefined input and output, that's fine
with me.  Maybe it will work better than my idea of defined http
interfaces for communication.

> One question: If our ATC only helps flights to avoid collision
and let them
> decide what course they follow (and there is no pre-defined
course), we may not
> need to manage the course change at all.

They need to ask permission for a course change so our FMS can
make sure their desired course change will not put them in
harm's way.  Once the coast is clear, we can give instruction to
the flight to make the course change.

> Besides, if the flights decide the
> course by itself, it may hit flights or objects which are not
managed by our
> ATC (we can know this from radar though), and the possibility
may be bigger
> than hitting managed flights. Are you sure to let the flights
decide the course
> by themselved? Isn't this too different from current ATC?

If obstacles are in the way, we guide the flights around them,
but otherwise let the flights choose their own path.  We are in
charge of short-term (within the next minute or so) navigation;
the flights are in charge of long-term navigation.

> BTW I have a good news for you: I won't touch java anymore,
until I get a fast
> computer... It's too terrible!

LOL

--Mike

Re: [Mratc-developers] [my status]

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> > Again, I list things that we've (maybe) been sure:
> >
> >
> >    R A D A R                       F L I G H T S
> >
> >      ||                                  ||
> >      ||                                  //
> >
> >       Flight management system  (is the name proper?)
> 
> Sounds good

:)

> 
> >  +--------------------------------------
> >  |  Database to store flight info
> >  |  Flight registration interface
> >  +--------------------------------------
> >      ||
> >      ||
> >      ||   ATC
> >  +--------------------------------------
> >  | Internal structure undecided
> >  +--------------------------------------
> >
> >
> > Radar: I don't know about the interface of radar system.
> Should we get info
> > from radar (if so, how?), or wait for it to send our system
> info about flights?
> 
> Unspecified at this time.  Whichever works best.  The interface
> should be as open and widely implemented as possible, without
> sacrificing performance.

Ummm... The problem is: The real radar system is not going to be developed by
us. So we need to know what interface the manufacturer will provide. Is this
possible, now?

> We don't want to tie radar
> manufacturers down to an obscure, poorly supported protocol.

CORBA :)

> The atc and radar systems should be fairly independent as well.
> The radar system might be owned and maintained by one entity
> while the atc system is owned and maintained by another.  Having
> database logins for the other system might be too much
> interdependence.  No user IDs or passwords for the atc-radar
> interface seems appropriate at this time.  The atc system should
> be able to keep functioning even if it loses contact with a
> radar system.  Also, a radar system should be able to keep
> functioning even if it loses contact with the atc system.  We
> can try to re-establish communications if they are lost, but not
> put the whole show on hold while we wait for communications to
> be restored.
> 
> > ATC: the only thing we can be sure that it has only one source
> of input and
> > output. But that's good enough for us to start working on :)
> 
> What do you mean by "one source of input and output?"

The flight management system. The ATC retrieve and send everything via it (and
only via it). By this method we may make the development of ATC easier, because
things in the flight management system such as communicating to radar or
flights are uncertain.

> 
> > BTW, what happened to mratc.org??
> 
> It's still around.  Since DNS changes didn't propogate fast
> enough, I removed all the flight hostnames (flight1 - flight15).
> There are still atc & radar hosts.  There is no www host, but
> there is a home page for the project at
> http://mratc.sourceforge.net/

One question: If our ATC only helps flights to avoid collision and let them
decide what course they follow (and there is no pre-defined course), we may not
need to manage the course change at all. Besides, if the flights decide the
course by itself, it may hit flights or objects which are not managed by our
ATC (we can know this from radar though), and the possibility may be bigger
than hitting managed flights. Are you sure to let the flights decide the course
by themselved? Isn't this too different from current ATC?

BTW I have a good news for you: I won't touch java anymore, until I get a fast
computer... It's too terrible!


=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] [my status]

[Michael R. <ht...@us...>]

----- Original Message -----
From: "Aquila Deus" <aqu...@ya...>

> Again, I list things that we've (maybe) been sure:
>
>
>    R A D A R                       F L I G H T S
>
>      ||                                  ||
>      ||                                  //
>
>       Flight management system  (is the name proper?)

Sounds good

>  +--------------------------------------
>  |  Database to store flight info
>  |  Flight registration interface
>  +--------------------------------------
>      ||
>      ||
>      ||   ATC
>  +--------------------------------------
>  | Internal structure undecided
>  +--------------------------------------
>
>
> Radar: I don't know about the interface of radar system.
Should we get info
> from radar (if so, how?), or wait for it to send our system
info about flights?

Unspecified at this time.  Whichever works best.  The interface
should be as open and widely implemented as possible, without
sacrificing performance.  We don't want to tie radar
manufacturers down to an obscure, poorly supported protocol.
The atc and radar systems should be fairly independent as well.
The radar system might be owned and maintained by one entity
while the atc system is owned and maintained by another.  Having
database logins for the other system might be too much
interdependence.  No user IDs or passwords for the atc-radar
interface seems appropriate at this time.  The atc system should
be able to keep functioning even if it loses contact with a
radar system.  Also, a radar system should be able to keep
functioning even if it loses contact with the atc system.  We
can try to re-establish communications if they are lost, but not
put the whole show on hold while we wait for communications to
be restored.

> ATC: the only thing we can be sure that it has only one source
of input and
> output. But that's good enough for us to start working on :)

What do you mean by "one source of input and output?"

> BTW, what happened to mratc.org??

It's still around.  Since DNS changes didn't propogate fast
enough, I removed all the flight hostnames (flight1 - flight15).
There are still atc & radar hosts.  There is no www host, but
there is a home page for the project at
http://mratc.sourceforge.net/

--Mike

[Mratc-developers] [my status]

[<aqu...@ya...>]

Hello!

sorry for disappearing... I was learning servlet and corba :)

Again, I list things that we've (maybe) been sure:


   R A D A R                       F L I G H T S

     ||                                  ||
     ||                                  //

      Flight management system  (is the name proper?)
 +--------------------------------------
 |  Database to store flight info
 |  Flight registration interface
 +--------------------------------------
     ||
     ||
     ||   ATC
 +--------------------------------------
 | Internal structure undecided         
 +--------------------------------------


Radar: I don't know about the interface of radar system. Should we get info
from radar (if so, how?), or wait for it to send our system info about flights?

ATC: the only thing we can be sure that it has only one source of input and
output. But that's good enough for us to start working on :)


BTW, what happened to mratc.org??

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] Define some ATC specifications

[Michael R. <ht...@us...>]

----- Original Message -----
From: "Aquila Deus" <aqu...@ya...>


> > Why multiply by 10 or 100?  We can build a scalable system,
but
> > initially, we just need to handle what's there.
>
> But we're building an ATC for the future. So it should be able
to handle the
> flights in next 20 or 30 years, right?

We should be able to scale up to meet the demands that will
develop in 20 or 30 years, but we do not need to test under
those conditions.  We just need to test and simulate under
current loads.

--Mike

Re: [Mratc-developers] Define some ATC specifications

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> > If we plan around handling US air traffic volume, we should be
> > able to handle volumes for any part of the world.  For the US,
> I
> > think a good maximum for the number of flights in the air at
> one
> > time is about 223,440.
> 
> How about multiply the number by 10 or 100?
> 
> Why multiply by 10 or 100?  We can build a scalable system, but
> initially, we just need to handle what's there.

But we're building an ATC for the future. So it should be able to handle the
flights in next 20 or 30 years, right?

> 
> > I have one good news and one bad news:
> >
> > The good news is I found a JVM optimized for extremely
> large-scale
> > applications: BEA's JRockit. And it supports lightweight
> threads (called "thin
> > threads").
> >
> > The bad news is the lastest version of JRockit seems to have
> removed the
> > lightweight threads :D
> >
> > I don't think it's good to use native threads or processes to
> emulate millions
> > of flights. Maybe we should really consider erlang seriously
> (but then we will
> > have to use emacs). Do you have a better solution?
> 
> I was thinking of approaching it with Perl and MySQL; you are
> invited to put together your best approach at the problem
> (unless you want to come along with me and Perl); and we will
> compare the two.  I think the scale involved here would benefit
> from a database, with its indexing capabilities.  If we both
> develop separate systems, we need to conform to some basic
> definitions (like having the same lookahead interval size and
> number and separating general flight direction by altitude),
> though, so we can compare apples to apples.
> 
> Threads can be done in Perl, if you are interested.  Yes,
> 223,440 threads sound like a lot.  I've been thinking iteration
> all along, rather than threads, so that number of flights does
> not discourage me.  However, we might get an ATC system put
> together that takes an hour to iterate through 223,440 flights.
> If that is the case, we can divide and conquer.

OK

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] Define some ATC specifications

[Michael R. <ht...@us...>]

----- Original Message -----
From: "Aquila Deus" <aqu...@ya...>

> If we plan around handling US air traffic volume, we should be
> able to handle volumes for any part of the world.  For the US,
I
> think a good maximum for the number of flights in the air at
one
> time is about 223,440.

How about multiply the number by 10 or 100?

Why multiply by 10 or 100?  We can build a scalable system, but
initially, we just need to handle what's there.

> I have one good news and one bad news:
>
> The good news is I found a JVM optimized for extremely
large-scale
> applications: BEA's JRockit. And it supports lightweight
threads (called "thin
> threads").
>
> The bad news is the lastest version of JRockit seems to have
removed the
> lightweight threads :D
>
> I don't think it's good to use native threads or processes to
emulate millions
> of flights. Maybe we should really consider erlang seriously
(but then we will
> have to use emacs). Do you have a better solution?

I was thinking of approaching it with Perl and MySQL; you are
invited to put together your best approach at the problem
(unless you want to come along with me and Perl); and we will
compare the two.  I think the scale involved here would benefit
from a database, with its indexing capabilities.  If we both
develop separate systems, we need to conform to some basic
definitions (like having the same lookahead interval size and
number and separating general flight direction by altitude),
though, so we can compare apples to apples.

Threads can be done in Perl, if you are interested.  Yes,
223,440 threads sound like a lot.  I've been thinking iteration
all along, rather than threads, so that number of flights does
not discourage me.  However, we might get an ATC system put
together that takes an hour to iterate through 223,440 flights.
If that is the case, we can divide and conquer.

--Mike

Re: [Mratc-developers] Define some ATC specifications

[<aqu...@ya...>]

--- Aquila Deus <aqu...@ya...> wrote: 
> I don't think it's good to use native threads or processes to emulate
> millions
> of flights. Maybe we should really consider erlang seriously (but then we
> will
> have to use emacs). Do you have a better solution?

I just found a big problem: there is no erlang developer (except for those
working in erisson). So let's forget about the sh|t....

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] Define some ATC specifications

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> Let's define some ATC specifications:
> 
> If we plan around handling US air traffic volume, we should be
> able to handle volumes for any part of the world.  For the US, I
> think a good maximum for the number of flights in the air at one
> time is about 223,440.

How about multiply the number by 10 or 100?

> - planes should have an enroute horizontal separation of 5
> nautical miles
> - planes at 28,000 feet will head 0 degrees, +/- 45 degrees
> - planes at 28,750 feet will head 45 degrees, +/- 45 degrees
> - planes at 29,500 feet will head 90 degrees, +/- 45 degrees
> - planes at 30,250 feet will head 135 degrees, +/- 45 degrees
> - planes at 31,000 feet will head 180 degrees, +/- 45 degrees
> - planes at 31,750 feet will head 225 degrees, +/- 45 degrees
> - planes at 32,500 feet will head 270 degrees, +/- 45 degrees
> - planes at 33,250 feet will head 315 degrees, +/- 45 degrees
> - planes will choose the heading that matches most closely their
> desired heading and request permission to fly at that altitude
> or heading
> - at mach 0.85, 5 nautical miles can be traveled in 35.9 seconds
> - one fifth of that is 7.2 seconds.  Let's have a lookahead
> interval of 7.2 seconds.
> - planes take about 10 seconds to turn 90 degrees (maximum
> course adjustment within an altitude)
> - 35.9 seconds (time to travel 5 nautical miles) plus 10 seconds
> (time to turn 90 degrees) is 45.9 seconds.  45.9 seconds can be
> spanned by 8 7.2 second lookahead intervals.  Let's lookahead 8
> intervals, or 57 seconds into the future, 7.2 seconds at a time.
> - let's keep planes separated by 6 nautical miles.  This
> provides a soft boundary to watch for planes that might approach
> the 5 nautical mile separation limit during an ATC compute
> cycle.
> - ATC cycle time to evaluate all flights might be set at 7.2
> seconds for now.  Maybe we should do it more often, maybe less,
> maybe we just start a new cycle whenever we finish the last one.
> 
> Let me know of any feedback you have about these specifications.
> Are they realistic?  Do they need adjustment?  That's all for
> now.

I have one good news and one bad news:

The good news is I found a JVM optimized for extremely large-scale
applications: BEA's JRockit. And it supports lightweight threads (called "thin
threads").

The bad news is the lastest version of JRockit seems to have removed the
lightweight threads :D

I don't think it's good to use native threads or processes to emulate millions
of flights. Maybe we should really consider erlang seriously (but then we will
have to use emacs). Do you have a better solution?

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

[Mratc-developers] Define some ATC specifications

[Michael R. <ht...@us...>]

Let's define some ATC specifications:

If we plan around handling US air traffic volume, we should be
able to handle volumes for any part of the world.  For the US, I
think a good maximum for the number of flights in the air at one
time is about 223,440.
- planes should have an enroute horizontal separation of 5
nautical miles
- planes at 28,000 feet will head 0 degrees, +/- 45 degrees
- planes at 28,750 feet will head 45 degrees, +/- 45 degrees
- planes at 29,500 feet will head 90 degrees, +/- 45 degrees
- planes at 30,250 feet will head 135 degrees, +/- 45 degrees
- planes at 31,000 feet will head 180 degrees, +/- 45 degrees
- planes at 31,750 feet will head 225 degrees, +/- 45 degrees
- planes at 32,500 feet will head 270 degrees, +/- 45 degrees
- planes at 33,250 feet will head 315 degrees, +/- 45 degrees
- planes will choose the heading that matches most closely their
desired heading and request permission to fly at that altitude
or heading
- at mach 0.85, 5 nautical miles can be traveled in 35.9 seconds
- one fifth of that is 7.2 seconds.  Let's have a lookahead
interval of 7.2 seconds.
- planes take about 10 seconds to turn 90 degrees (maximum
course adjustment within an altitude)
- 35.9 seconds (time to travel 5 nautical miles) plus 10 seconds
(time to turn 90 degrees) is 45.9 seconds.  45.9 seconds can be
spanned by 8 7.2 second lookahead intervals.  Let's lookahead 8
intervals, or 57 seconds into the future, 7.2 seconds at a time.
- let's keep planes separated by 6 nautical miles.  This
provides a soft boundary to watch for planes that might approach
the 5 nautical mile separation limit during an ATC compute
cycle.
- ATC cycle time to evaluate all flights might be set at 7.2
seconds for now.  Maybe we should do it more often, maybe less,
maybe we just start a new cycle whenever we finish the last one.

Let me know of any feedback you have about these specifications.
Are they realistic?  Do they need adjustment?  That's all for
now.

--Mike

Re: [Mratc-developers] Interesting article about OO

[Michael R. <ht...@us...>]

Yes, interesting.

--Mike

----- Original Message -----
From: "Aquila Deus" <aqu...@ya...>
To: "mratc.dev" <Mra...@li...>
Sent: Monday, August 16, 2004 2:55 AM
Subject: [Mratc-developers] Interesting article about OO


> http://www.paulgraham.com/noop.html
>
> :)
>
> =====
> me = d2004xx = d2003xx = d2002xx
>
>
>
>
>
>
___________________________________________________________ALL-N
EW Yahoo! Messenger - all new features - even more fun!
http://uk.messenger.yahoo.com
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on
Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only
$33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free
Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Mratc-developers mailing list
> Mra...@li...
> https://lists.sourceforge.net/lists/listinfo/mratc-developers

[Mratc-developers] Interesting article about OO

[<aqu...@ya...>]

http://www.paulgraham.com/noop.html

:)

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] Things we need before implementing ATC

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> > BTW, I think ATC is not only for avoiding collision, right? Is
> there other
> > thing we need to consider?
> 
> Like what?  I can't think of anything else.

flights landing, course management, ... contact to airports?

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Re: [Mratc-developers] Things we need before implementing ATC

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> 
> > I have some examples:
> >
> > AtcToRadarInterface
> >   |
> >   |-- AtcToRadarRemote
> >   |     |
> >   |     |-- AtcToRadarRemoteViaHTTP
> >   |     |
> >   |     |-- AtcToRadarRemoteViaIPC
> >   |
> >   |-- AtcToRadarLocal   (which calls Radar functions locally)
> >         |
> >         |-- AtcToRadarLocalDebug (print everything on console)
> 
> Local vs remote abstraction can be accomplished at the IP
> addressing layer.  Want to talk to a process on the local
> machine?  Use the local machine's IP address.  Want to talk to a
> process on another machine?  Use that machine's IP address.
> It's just a matter of changing the IP address.

My "Local" there is actully to call the radar's functions in the same process,
not to call different processes on the local computer.

> 
> The closer the communication over the network is to self, the
> faster it happens, in a significant kind of way.  Pinging self
> takes maybe 0.03 ms.  Pinging a machine on the LAN might take 3
> ms.  Pinging something on the Internet might take 30 ms.  From
> this, we can see that IP communication with self is two orders
> of magnitude faster than talking with another machine on the LAN
> and three orders of magnitude faster than talking with a machine
> on the Internet.  The performance improvements gained from
> working closer to home are not lost in using IP networking for
> IPC.  Still, IPC (in any form) is more costly than keeping
> communications within the process.  We should try to keep IPC at
> minimum levels.
> 
> If we count database communications as IPC, I guess we will be
> doing a lot of it.  Database interfaces have undergone a lot of
> testing, debugging, and optimization, however.  They seem like
> robust and reliable channels for IPC.

Ah no. In fact my IPC means Unix's System V IPC only. Because there is shared
memory, which can require almost zero CPU time to communicate.

> 
> Rather than debugging to console, we might want to log to log
> files.  That's what Apache and MySQL do.  It is very effective
> in helping me understand what's going on in daemon processes
> that are not tied to a particular console.  Since all logging
> will be sent to a file in the local filesystem, there is no need
> for remote logging.  If someone on a remote machine wants to
> watch a log, they can secure shell into the remote machine and
> watch the log once logged in.  In Linux, this can be
> accomplished with the tail utility.  With it, a log file can be
> watched so that all new entries in the log show up on the screen
> as if the process were logging straight to the console.  I don't
> know if Windows has a utility like that.

cygwin :)

> 
> > BasicFlightRequest
> >   |
> >   |-- ChangeCourseRequest
> >   |
> >   |-- AirportRelatedRequest
> >         |
> >         |-- LandingRequest
> >         |
> >         |-- TakingOffRequest
> 
> I am not seeing much advantage here over structural-oriented
> programming.  All these communication requests can be
> accomplished in single, simple, flat http transactions.

True. It's not a good example :)

One reason to use inheritance is that when we're not sure what will be needed
in future, it's better to create a new class based on the base class rather
than to let the base class define things we will need/extend.

> 
> > > I could lay out a structure-oriented plan if you are
> interested.
> > > I've got one in my mind.  I just haven't felt the need to
> put it
> > > down in writing yet.  I was thinking I would just go
> straight to
> > > implementing the plan in database tables and code.
> Sometimes
> > > writing out decent plans is about as involves as writing
> actual
> > > code, so why not just go straight from ideas to code?
> >
> > How about write some scripts now and convert them to OO later?
> 
> Sounds good to me.
> 
> > I think we could code flight and radar simulation directly.
> And it may be
> > better to combine the two, since they are not our main
> business, and this
> > should reduce some complexity for ATC (one source to get info
> about flights).
> 
> We should code our simulators as close to the functionality of
> the real thing as possible, since aircraft and radar vendors
> will use them for network API and functionality guides when they
> implement actual flight control and radar systems.  It will also
> help us expose and address any problems that might be associated
> with that particular kind of design.

ok

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com