Estimating atmospheric drag in the LeoReducedDynamicOrbit scenario

[WmjTonald]

Dear Developer,

I hope this message finds you well.

As a beginner with GROOPS, I am currently working on estimating atmospheric drag force using the LeoReducedDynamicOrbit scenario to invert atmospheric density.

I have noticed that the design matrix is parameterized within the "ParametrizationAccelerationModelScale::compute()/ParametrizationAccelerationThermosphericDensity::compute()" function. However, when I adjust the parameters (as shown in pic1), the resulting atmospheric drag force model scaling factor becomes negative (see pic2). Additionally, when I set the atmospheric density (as illustrated in pic3), it also results in a negative value (refer to pic4). These outcomes seem illogical.

Could you please advise me on how to address this issue?

Thank you for your assistance.

Best regards,
Wu Mengjun

[ajs8041]

Dear Mengjun,

You are obviously right, negative densities are physically meaningless.

This result is usually a strong hint that something went wrong already earlier. In general, any faulty parametrization or mismodeling of forces is going to end up in the final result, which is exactly what you observe. For instance, I see that you use the orbit of GRACE-FO and add some parametrizationAcceleration gnssSolarRadiation. GnssSolarRadiation is meant for GNSS satellites and not for modeling the radiation pressure acting on GRACE-FO. This is one likely reason for you unphysical results.

Best regards,
Andreas

[WmjTonald]

04groopsGnssProcessing.xml
Dear Andreas,

Thank you for your helpful feedback — I fully agree that negative densities indicate upstream modeling or parametrization issues.

Following your advice, I revisited my force modeling and parametrization strategy. Currently, I am using a configuration where the atmospheric drag scale factor (modelScale → atmosphericDrag) is estimated at 90-minute intervals, and the Y/Z per-revolution empirical accelerations are estimated at 120-minute intervals. With this setup, the inverted atmospheric densities agree with the JB2008 model at the level of within 5%.

At this stage, I would greatly appreciate your insight on a few points:

1. Experience at TUG
   Has TUG conducted similar experiments focusing on recovering atmospheric density primarily through orbit determination? In your experience, is there a recommended parametrization strategy (e.g., different arc lengths, stochastic modeling, or empirical acceleration settings) that enables high-resolution and high-accuracy density retrieval relying mainly on the estimated drag scale factors?

2. Reproducing TUG reference density files
   I am interested in generating density products comparable to the TUG reference files (e.g., gracefo1_density_yyyy_mm.txt.gz). Is it mandatory to include onboard accelerometer data to reach that level of quality, or is it feasible—though perhaps with reduced accuracy—to derive comparable densities using GNSS-based POD alone?

3. Differences between TUG and TUDelft densities
   I notice relatively large discrepancies between the density products provided by TUG and TUDelft. Do you have recommendations on which aspects of the modeling chain are most critical to review or optimize (e.g., macro-model, attitude handling, background atmosphere, accelerometer calibration)? I have attached the relevant comparison files for your reference.

Thank you again for your time and support. Your guidance has been extremely valuable for improving my processing strategy.

Best regards,
Mengjun
03groopsVariational.xml
04groopsGnssProcessing.xml
GC_DNS_ACC_2020_0101_v02.txt
gracefo1_density_2020_0101.txt

[ajs8041]

Dear Mengjun,

without checking the details of your scripts, 5% sounds very good - in fact, if you did not provide that number, I would have assumed the model is further from reality than that.

Concerning your questions:

1. We do not use the exact same approach, so I can not give you a precise recommendation on your parametrization strategy. Finding the best arc length tends to be some trial and error game. To me, your choices do not sound unreasonable.
2. The density files on our ftp are processed from accelerometer data (this is true for GRACE and GRACE-FO), the details seen in these data will not be reproduced with a POD-only strategy. However, if we do not concern ourselves with details, POD-derived densities offer a nice fit (which must be true, since POD is used to estimate bias/scale of the accelerometer).
3. Yes, I am very aware of these differencies. And since you are already aware of the necessity that is accelerometer calibration, this is the key contributor to the differencies we observe in these datasets. However, I will soon push an update to our ftp, that uses a POD based calibration scheme, which is what TU Delft uses (and also others, like University Bremen). However, there are also other contributions to these differences (that I know of - in reality there is going to be several tiny choices that one overlooks): macro model is slightly different, thermal radiation pressure modeling for GRACE-FO is different (density-wise this is a pretty small factor), I assume they use the same atmospheric model (DTM2020) for temperature and composition of the atmosphere (needed as input for the calculation of the drag (+lift) coefficient)... Additionally, the modeling of the thruster activity was faulty on my part. As of now (unpublished), they look pretty similar:

Finally:
https://repository.tugraz.at/publications/c23ww-bch83 - the dissertation of my colleague Barbara Süßer-Rechberger. You might want to check out chapter 7.1.2 for how we process densities from kinematic orbits.

Best regards,
Andreas