Adding support for calendar/clock time #1047
Replies: 3 comments 4 replies
-
|
I have a small preference for the XML element option since that would make the parser agnostic to the local date format. The examples you gave are in the North American format MM-DD-YYYY but there are other formats such as DD-MM-YYYY which is used in France (and possibly other countries) and YYYY-MM-DD which is the international date format. In addition this calendar/clock time could be propagated to the MSIS atmosphere model which also uses calendar/clock time albeit in a much cruder way:
Also beware to time zones and the daylight saving time which make the conversion quite tricky when the date is not supplied as UTC or the OS local time. |
Beta Was this translation helpful? Give feedback.
-
|
Good suggestions - Thanks. I think you make good arguments for the element approach over the attribute approach. |
Beta Was this translation helpful? Give feedback.
-
|
Also while I was responding to the discussion #1045, I have seen that jsbsim/src/models/flight_control/FGMagnetometer.cpp Lines 73 to 90 in 3d95aeb |
Beta Was this translation helpful? Give feedback.
-
|
Out of interest @jonsberndt what sorts of use are you thinking of? Comparing JSBSim orbital data to other orbiting objects via ephemeris data, e.g. relative location of JSBSim orbiting object and the space station? Based on my experience writing software for flight planning I'm familiar with geomagnetic models like - https://www.ncei.noaa.gov/products/world-magnetic-model that are time dependent. Actually as per @bcoconni's mention of the magnetometer sensor we actually have an implementation of a geomagnetic model (albeit out of date) in - https://github.com/JSBSim-Team/jsbsim/blob/3d95aeb751e6ddd11b1007571b86662cd41612d8/src/simgear/magvar/coremag.cxx My other experience in terms of data that is time dependent is weather forecast data, e.g. winds aloft in a grid pattern at multiple flight levels over say a 48hr forecast period at say 3hr intervals. So I can see the new current date/time being used by C++ code like the geomagnetic model etc. but also possibly via XML data supplied by the user, e.g. forecast wind data to inject/update the current wind vector in JSBSim based on 3D position of the aircraft and current date/time by looking up the forecast wind data in a breakpoint based table for example. If we wanted to support XML data making use of the current date/time we'd need to think of how to handle that in terms of how the date/time is specified for example in a breakpoint table etc. |
Beta Was this translation helpful? Give feedback.
-
|
Sean, That's exactly what I am thinking. First, I think that it would be generally helpful and informative if we could provide something other than simple seconds elapsed time since the sim started. Actual local or UTC time would, I feel, be generally useful. So, there's that. Second, I would like to be able to convert J2K inertial frame to the local ECEF frame. JSBSim can already accept initial conditions in ECEF, so if we can convert J2K state to ECEF, I think that would be a positive thing. For the conversion, we need J2K time. I wrote a test program below that I have tested and which seems to work well. It was really initially just sort of an exercise for me, for fun. But, the time calc seems to work well. The next step is to calculate the Earth rotation angle. So, of course this is where it gets more complex, because at this point in time the rotation from J2K into ECEF isn't simply a rotation about the rotation axis. Nutation and precession have an effect. However, I thought it would be OK to start with that. There are several satellites (including ISS) that publish location data publicly, so I thought it would be fun to experiment. #include <ctime>
#include <cstdio>
#include <iostream>
#include <cmath>
#include <cstring>
#define modulo(X,Y)
double getJulianDay(int day, int month, int year, int hour, int minute, int second);
double getEarthRotationAngle(double J2Kdate);
using std::string;
int main(int argc, char** argv)
{
struct tm j2000;
struct tm* ptime;
double J2Kdate;
double ERA = 0;
char buf[20];
uint year, month, day, hour, minute, second;
if (argc == 2) {
if (strlen(argv[1]) == 19) {
year = std::stoi(string(argv[1]).substr(0,4));
month = std::stoi(string(argv[1]).substr(5,2));
day = std::stoi(string(argv[1]).substr(8,2));
hour = std::stoi(string(argv[1]).substr(11,2));
minute = std::stoi(string(argv[1]).substr(14,2));
second = std::stoi(string(argv[1]).substr(17,2));
} else {
//std::cerr << "Input date string (if any) must be of the form YYYY-MM-DDTHH:MM:SS[.###], e.g. 2023-12-21T02:09:10.000\n");
std::cerr << "Input date string (if any) must be of the form YYYY-MM-DDTHH:MM:SS, e.g. 2023-12-21T02:09:10\n" << st
d::endl;
return(-1);
}
}
time_t now = time(NULL);
j2000.tm_sec = 56; // actually, 55.816
j2000.tm_min = 58;
j2000.tm_hour = 11;
j2000.tm_mday = 1;
j2000.tm_mon = 0;
j2000.tm_year = 100;
j2000.tm_isdst = 0;
time_t then = mktime(&j2000) - timezone;
double diff = difftime(now,then);
sprintf(buf,"%12.5f\0",diff/86400.00);
std::cout << "Current J2000 time (days): " << buf << " (timezone: " << timezone/3600 << ")" << std::endl;
// print Julian Date
double JD1 = getJulianDay(1,1,2000,11,58,56);
j2000.tm_sec = second;
j2000.tm_min = minute;
j2000.tm_hour = hour;
j2000.tm_mday = day;
j2000.tm_mon = month-1; // January is 0
j2000.tm_year = year - 1900; // years since 1900
j2000.tm_isdst = 0;
// j2000.tm_sec = 0;
// j2000.tm_min = 0;
// j2000.tm_hour = 12;
// j2000.tm_mday = 1;
// j2000.tm_mon = 0; // January is 0
// j2000.tm_year = 100; // years since 1900
// j2000.tm_isdst = 0;
double JD2 = getJulianDay(j2000.tm_mday,
j2000.tm_mon + 1,
j2000.tm_year + 1900,
j2000.tm_hour,
j2000.tm_min,
j2000.tm_sec);
char* mydate = asctime(&j2000);
J2Kdate = JD2 - JD1;
mydate[std::strlen(mydate)-1] = 0l;
sprintf(buf,"%12.5f\0", J2Kdate);
std::cout << "J2000 time for date " << mydate << " (UTC): " << buf << std::endl;
ERA = getEarthRotationAngle(J2Kdate);
std::cout << "Earth Rotation Angle (deg): " << ERA << std::endl;
}
double getJulianDay(int day, int month, int year, int hour, int minute, int second)
{
int a = floor((14-month)/12);
int y = year + 4800 - a;
int m = month + 12*a - 3;
// Julian day from the Gregorian Calendar
double JD = day + floor((153*m + 2)/5) + 365*y + floor(y/4)
- floor(y/100.0) + floor(y/400.0) - 32045.0
+ (hour - 12.0 + minute/60.0 + second/3600.0)/24.0;
return(JD);
}
double getEarthRotationAngle(double J2Kdate)
{
double ERA = (280.46062 + 15.04106688*J2Kdate)/360.0;
ERA = ERA - long(ERA);
ERA *= 360.0;
return ERA;
} |
Beta Was this translation helpful? Give feedback.
-
|
Hey @jonsberndt, Just a small tip when posting C++ code or XML on GitHub, you can add the language name after the first triple back tick to enable syntax highlighting. For example, for XML you can open the code snippet with |
Beta Was this translation helpful? Give feedback.
-
|
I did not know that! Thanks! |
Beta Was this translation helpful? Give feedback.
-
There may be occasions where we wish to run a simulation for a very specific date and time. I've been thinking for a while that I'd like to add support for this. I would think that such a date/time - an epoch - would be specified in a script file. The question I have is whether such a specification would be an attribute or an element. Taking the ball_orbit_phase script for example, this might be one way to do it, if the epoch is an attribute:
Another way would be to specify the epoch as an element:
Yet another way could be:
Internally, this should not be that hard. The effect of the above would be that we would simply specify the start of the epoch. The current date/time would then simply be the start time plus the elapsed sim time.
Any thoughts?
Beta Was this translation helpful? Give feedback.
All reactions