Jpl horizons algorithm delta t

[ssimard2504]

This pull request addresses a single issue:

Update the JPL Horizons Delta-T algorithm to be in-line with JPL Horizons application. The revised algorithm is based on initial guidelines generously provided by Jon Giorgini (JPL) and from information available within the JPL Horizons app user manual:

Jon Giorgini
Senior Analyst
Solar System Dynamics Group (392R)
Navigation and Mission Design Section
Jet Propulsion Laboratory
Pasadena, CA USA
[email protected]

source : JPL Horizons app user manual: https://ssd.jpl.nasa.gov/horizons/manual.html

Description

Changes required to three (3) .cpp files: StelCore.cpp, StelUtils.cpp, StelGuiItems.cpp
Changes required to two (2) .hpp files: EphemWrapper.hpp, StelUtils.hpp,
Changes required to one test case: testDeltaT.cpp

As documented in issue #4670, the motivation is essentially to resolve unrealistic deltaT values (i.e.. 0.0) outside the time range (3000BC to 1620) of the previous algorithm and to improve accuracy and concordance with JPL Horizons app.

This change requires access to a routine which can compute leap seconds from 1962-10-20 to present. Software from the ERFA library was integrated within Stellarium and build by CMake as a static external library. It still remains to the Stellarium team to decide if this integration is legally valid.

Screenshots (if appropriate):

None

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update
• Housekeeping

NOTE Stellarium User Guide needs to be revised to clarify the need for the use of new JPL DE* files and how to properly use Stellarium and interpret Delta-T results.

How Has This Been Tested?

Section relevant to JPL Horizons algorithm within testDeltaT.cpp has been revised. Reference data were extracted from JPL Horizons app and compared with values obtained by Stellarium. Differences between Stellarium and JPL Horizons are as follow:

from 9999BC to 1962-01-20 : les than +/- 0.1 seconds differences
from 1962-01-20 to 2650-01-25 : less than +/- 10 microseconds differences
from 2650-01-25 to 9999AD : less than +/- 2 milliseconds differences

It is not expected that this change affect other area of the code. HOWEVER, a modification to getMoonSecularAcceleration() limiting this effect to JD < 1955.5 has been added which may impact other DeltaT algorithm if they are not based on this same assumption. This need to be investigated further.

Test Configuration:
• Operating system : Windows 11 Pro, 25H2, OS build 26200.7171
• Processor : 13th Gen Intel(R) Core(TM) i7-13700K (3.40 GHz)
• Graphic Card : NVIDIA GeForce RTX 5050 Ti
• Driver : 581.80
• Display : ASUS PA329CV, 3840x2160 | 60 Hz | Highest (32-bit) | HDCP

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• [x ] I have commented my code, particularly in hard-to-understand areas
• [x ] I have made corresponding changes to the documentation (header file)
• I have updated the respective chapter in the Stellarium User Guide
• [x ] My changes generate no new warnings
• [x ] I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[gzotti]

Thanks, definitely interesting, although I have no time to fully testdrive this in these weeks. Hopefully just around turn-of-the-year. I think, when we integrate ERFA, we should set this up via CPM like many other tools we changed from earlier "exernal"izing. But I am no expert in this setup, @alex-w, @10110111 ? You wrote you used cmake to build it, indicating its own installation instructions around yet another tool, meson, is not required? And then we might eventually utilize more of ERFA as time comes.

[ssimard2504]

I analyzed the failure on Linux and macOS and I believe that it is caused by an invalid value of TTmTDB from test case JD 2437684.50000, with DeltaT expected at 34.051667 seconds.

This test case happens to be the very first one in the time range 1962-01-20, which mean that we now need TTmTDB extracted from linux_p1550p2650.440t to compute DeltaT to +/- 10 microseconds of JPL Horizons results. If the request to get TTmTDB is not available when we reach this first test case, then GetDe440Coor() will return deOK false (see line 2017 of StelUtils.cpp) and TTm TDB will fall back to 0.0.

On my Windows-based system, I debugged the code of testDeltaT.cpp (with breakpoints) and saw TTmTDB = -0.000467609 second at JD = 2437684.50000, with lead seconds = 1.8671988 seconds. DeltaT is computed as follow : deltaT = 32.184 - TTmTDB + leapSeconds. If TTmTDB = 0, we would get DeltaT = 34.05120, which is not within the +/- 10 microseconds criteria, but if TTmTDB = -0.000467609, we would get DeltaT = 34.05167, which is within the +/- 10 microseconds criteria.

So bottom line, for some reason, Linux and macOS are not ready to extract TT-TDB for this very first test case in the range of 1962-01-20 and up, but works for all the others test cases within that rnage...

So the question is why Linux and macOS fail to be ready accessing the linux_p1550p2650.440t file on this very first request while Windows seems to be ready ?

Note: while numbers reported by this automated review match my analysis, it remains to be proved... Someone should investigate on a Linux and macOS computer if this is really the case. I don't have a Linux and macOS computer, but I am more than willing to help out if needed.

[ssimard2504]

@gzotti ... You wrote you used cmake to build it, indicating its own installation instructions around yet another tool, meson, is not required?

I did not need to use meson tool. I personally do not know this tool. I simply copied all the *.c and *.h files of ERFA in a directory, and first used Visual Studio 2026 to build a static library out of them. I realized within this development environment that I had to set some macros manually (which probably meson was taking care...), and fixed the code in some files (those were not related to SOFA, but very specific to ERFA, and these changes are very minor and have no impact on astrometry calculation). Then I figured out how this building process could be automated by CMake within Stellarium.

I more or less followed the same approach that I used to integrate the original SOFA library as I mentioned in issue #4670. The first step of the Pull Request is specific to the integration of ERFA into a static library, with all the changes in the CMakeLists.txt files needed. I understand that your team would prefer to integrate via a different approach (like CPM) if ERFA is an acceptable source of code. I have no issue with that.

I do hope that you will eventually integrate this new functionality in Stellarium. If not, well, with this Pull Request you have all the details on how JPL Horizons compute Delta_T, so Enjoy!

[ssimard2504]

I run testDeltaT.cpp in Debug, Release and RelWithDebInfo build configurations on my Windows PC. The following three files are the respective output of test results that I get from these runs:

TestDeltaT_Debug_2025-11-27_2136.txt
TestDeltaT_Release_2025-11-27_2142.txt
TestDeltaT_RelWithDebInfo_2025-11-27_2142.txt

What I am noting is that the failure report from Linux and macOS build by CI Workflow run do not show the QINFO that I normally get during the initTestCase() execution. Most notably

QINFO : TestDeltaT::initTestCase() Use DE440 ephemeris file "C:\Users\simar\AppData\Roaming\Stellarium/ephem/linux_p1550p2650.440t"
QINFO : TestDeltaT::initTestCase() DE440 init successful. JD range 2287184.5000..2688976.5000

Are these automated test cases, aware that they need to use the t version of the DE440 files ?

The QINFO also shows if the DE440 initialization was successful, but it does not appear on the CI Workflow run...

I just update testDeltaT.cpp and pushed it to the same branch. I only added more comments to identify the calendar dates (using mixed calendars) to each tested Julian Date. The code has not changed so CI Workflow run should report the same failures. We'll see...

[10110111]

You wrote you used cmake to build it, indicating its own installation instructions around yet another tool, meson, is not required?

ERFA doesn't use meson, it uses autotools (which is based on Bourne shell, and I'm not sure if our Windows build environment works well with it). This makes it less suitable for use with CPM. But at the same time, we don't want to always use the bundled version, since ERFA is packaged in at least some Linux distributions (e.g. Ubuntu since 22.04).

Given all this, I suppose we should check for a local erfa package using pkg_check_modules from FindPkgConfig package. Then, if we still haven't found it, build the bundled one.

Another option would be to host a version of it converted to CMake, and then use it with CPM.

[ssimard2504]

I tried to push the ephem folder which contains all my DE files needed for properly testing the new algorithm . This folder includes very big ones (more than 2GB each). The git push fails pathetically... Is there any way someone at your end can ensure these files are accessible in stellarium/ephem before the automated CI test is executed ? Maybe this is the reason why it fails on some platform like Linux and macOS, but not on Windows..

[10110111]

This folder includes very big ones (more than 2GB each). The git push fails pathetically

And rightly so. Who will ever want to download useless extra 4GB of data when fetching the source repo?

Normally all these files are downloadable during runtime (Configuration → Extras). I suppose the unit tests that require these files should be optional. Or, if it's possible, they could make use of some small substitutes (or even mock functions) that contain all the information necessary for the test.

[alex-w]

@ssimard2504 where we should get these files?

[gzotti]

The location and download of the optional DE4* files is described in the User Guide. No, these certainly won't go into the repo, and are always optional. Most users won't ever need them, and I expect most users also won't bother. (Of course I do like the prospects of getting so much closer...)

I also know nothing about *.440t files. When the data files are missing, the test should still succeed with just a warning that it could not be performed on the original data files. Testing locally on a dev PC is then more helpful.

ERFA doesn't use meson, ... (@10110111 )

The building instructions say so, but I did not go further. The fewer extra tools the better. And if erfa is an available installable library on Debian-based systems, then yes, either use that or "USE_BUNDLED_ERFA" with sources either fetched ad-hoc (CPM?) and prepared for building with addition of e.g. one extra CMakefile, or we can still add a snapshot into external (and update this every 2 years or so?) and use that on Windows or whereever it is not pre-installed.

[ssimard2504]

The DE4* files are indeed described in the user guide (page 65) and a link is even provided at the bottom of the page to find them: https://ssd.jpl.nasa.gov/ftp/eph/planets/Linux/ .

As per the 'current' user guide instructions, they have to be downloaded separately and are optional. They should be saved either in the user directory or installation directory, in a separate folder named /ephem.

Or they could be saved in another location specified in the config.ini file as described in the user guide on page 65. However, this 3rd option does not work for some test cases (e.g. testEphemeris and testDeltaT that I recently modified to support testing JPL Horizons algorithm). In their cases, they have to be either in the user directory or installation directory.

The new DE4* 't' files required for JPL Horizons are also available from the same JPL FTP website. The 't' version of DE430 and DE440 contains the data to extract TT - TDB from the ephemerides, which the JPL Horizons algorithm needs from date 1962-01-20 and Present.

@10110111 ..And rightly so. Who will ever want to download useless extra 4GB of data when fetching the source repo?

I am fairly new to all this business of git, CI, repo and whatnot. I had no idea that pushing large file was a no-no in this business. I was just attempting to figure out why testDeltaT was failing on Linux and macOS while it works fine on my Windows system. Since the test will not discover the files unless they are in the user or installation directory, I thought, why not upload them in the installation directory for the CI testing ?

From all these discussions, I am reading between the lines that there are two philosophies at play here: The 'good enough' and the 'accurate'. I personally falls in the 'accurate' group and would much prefer that Stellarium aims for this goal in future release, though not if there is a significant penalty on performance.

@gzotti ... When the data files are missing, the test should still succeed with just a warning that it could not be performed on the original data files. Testing locally on a dev PC is then more helpful...

I guess I could modify the portion of testDeltaT testing JPL Horizons algorithm to act like testEphemeris if the DE4* files cannot be found. I'll do that later today.

[gzotti]

I guess 80-95% of users want today's sky and nothing else, and are happy to find and observe objects in their modest instruments. This requires "good enough" and worked many years ago. Here VSOP87 should still be sufficient, and is small enough to run on SBCs with limited storage/power. Here probably even devs don't want to run the tests with huge files, although building customized installs should always work. And then there are the scientific users who want more, be it higher accuracy or simulation in historical context. This is why we did a lot to improve accuracy, including DE4* use, but I stopped with aberration and don't care for gravitative light deflection or similar sub-arcsecond things. (This should not prevent others from doing it...) Some of those users may have the files already in their systems which is why you can configure other locations via config.ini to avoid duplicate gigabytes. Else, the user data directory's ephem subdirectory is the expected place. The program install directory happens to work by the way the directory searching works but should actually not be recommended (We should fix that sentence. Users should not mess around copying stuff there...).

To test the Linux issues on a Windows PC, you can build everything under WSL2.

If I install the .430t/.440t files, do I still need the non-t as well or do they include all data? In this case we can then change instructions...

[ssimard2504]

@gzotti ... If I install the .430t/.440t files, do I still need the non-t as well or do they include all data? In this case we can then change instructions...

My understanding is that the .430t/.440t files are a superset of .430/.440. That is they should give the same position/velocity information of sun & planets but in addition, the 't' version includes Chebyshev polynomial
coefficients fit to the integrated value of TT-TDB evaluated at geocenter.

This is what I read from the README file for de430t that you can find here:

https://ssd.jpl.nasa.gov/ftp/eph/planets/Linux/de430t/

README.txt

There is no README file for the de440t, but I would imagine this is also applicable to the de440t version.

I kept both type of files for this development on my PC and so far I did not see any differences in RA/Dec when switching between them. However this is very limited check of mine.... On the other hand test case "testEphemeris" give a PASS with the 't' version, so it is pointing in the right direction.

If you want to use these 't' version files, you must download them in the same location as the other de files. But you also have to modify two MACROs in EphemWrapper.hpp and rebuild Stellarium.

#define DE430_FILENAME "linux_p1550p2650.430t"
#define DE431_FILENAME "lnxm13000p17000.431"
#define DE440_FILENAME "linux_p1550p2650.440t"
#define DE441_FILENAME "linux_m13000p17000.441"

Bottom line, to answer your question, changing instructions in the user guide to use the 't' version should do it for now.

IF, however, the Stellarium team go ahead to incorporate the new JPL Horizons Delta-T algorithm as I propose, the user guide will need a bit more changes and/or the Stellarium GUI may need to hook the activation of DE44x automatically when the JPL Horizons Delta-T algorithm is selected...otherwise all Delta-T after 1962-01-20 will be off by a huge.... 2 milliseconds ;-)

[alex-w]

hmm... what about JPL Delta-T when VSOP87 selected?

[gzotti]

IIRC we activate JPL DE* ΔT when DE* is used, not the other way. @ssimard2504 indicates when setting JPL ΔT results will be off by 2ms which I don't notice given likely other noise. What I am still unclear after all these years (or have forgotten) is the actual effect of the different ndots. Where do they impact? Lunar position?

[ssimard2504]

@alex-w, @gzotti when the JPL Horizons algo is selected and VSOP87 ephemerides are used (instead of DE44x) Stellarium will still compute Delta-T using the JPL algorithm, however, the correction for Moon Secular Acceleration for all years before 1955.5 will give a correction different from the JPL Horizons app.

JPL 44x ephemerides n_dot (i.e. variable ephND) = -25.936 "/cy/cy, while VSOP87 ephemerides n_dot (ephND) =-23.8946 "/cy/cy. Since JPL Horizons algo is based on n_dot (nd) = -25.82 "/cy/cy (the same as for DE43x), the correction between VSOP87 and DE44x will be different - being computed as a function of (ephND - nd).

Note that you could have selected DE440 (only this one...) from the Ephemeris settings GUI and still fallback to VSOP87 if you end-up selecting a date outside the range of DE440. DE440 covers 1549-12-21 to 2650-01-25 (assuming mixed calendar). So for a date like 1500-01-01 the Ephemeris used will be those of VSOP87, not DE440.

For years after 1955.5 the Moon Secular acceleration correction should not be applied according to my email with Jon Giorgini (JPL). This is how JPL Horizons app work. I therefore added a line of code in getMoonSecularAcceleration() to return 0.0 for this correction for all years after 1955.5. I HAVEN'T VERIFIED IF THIS IS ALSO APPLICABLE TO THE OTHER DELTA-T ALGORITHMS, which is why I flagged it in the PR. It will be important to validate that all algorithms expect no Moon Secular Acceleration correction after 1955.5

Finally, for dates after 1962-01-20, the JPL Horizons algo compute TDB - UTC and use the DE440 file to get TT-TDB and eraDat() to get leap seconds. If DE440 is not selected in the Ephemeris settings, then we loose a small correction of around +/-2 milli-seconds (i.e. TT - TDB) which is why we originally fail the CI test since my criteria was +/- 10 microseconds of matching JPL Horizon app.

I have update testDeltaT.cpp and testDeltaT.hpp to bypass the test if file linux_p1550p2650.440t is not found. So far Linux, macOS and Windows are successful. So it looks like the automated CI test just didn't have access to the file for Linux and macOS... but Windows had (very strange...)

[10110111]

So it looks like the automated CI test just didn't have access to the file for Linux and macOS... but Windows had (very strange...)

No test has. Windows CI simply doesn't run any tests.

[ssimard2504]

@gzotti : feel free to comment and challenge. I am in a learning phase in this field and may got this all wrong...

Technical Note: Lunar Secular Acceleration correction with an epoch cut-off at 1955.5

Background

Stellarium currently applies a lunar secular acceleration correction term to all ΔT algorithms (with few exceptions) regardless of epoch. This practice is inconsistent with the way JPL Horizons application applies this correction. The JPL Horizons imposed a cut-off at 1955.5 for this correction, because JPL ephemerides are not based on a specific lunar theory after the atomic era, but are for pre-atomic era.

However, Stellarium relies principally on the VSOP87/ELP2000-82B sun/planets/lunar analytical ephemerides theory which is based on a specific n_dot value of -23.8946"/cy/cy. Does this theory requires the same cut-off as required by JPL ephemerides or should it be implemented as in the current Stellarium version (25.3), i.e. regardless of epoch.

Key point

The semi analytical lunar theory ELP2000 82B (Chapront Touzé & Chapront 1983, 1988) was explicitly fitted to JPL numerical integrations (DE200/LE200, later DE245/DE403). These JPL integrations already include the tidal secular acceleration of the Moon. Therefore, the fitted constants of ELP2000 82B inherently account for lunar secular acceleration for post-atomic time era. Applying an additional ΔT correction term after the atomic era (≈1955.5) will double counts the effect.

Supporting references

• Chapront Touzé & Chapront (1983), Astronomy & Astrophysics 124, 50
• Chapront Touzé & Chapront (1988), Astronomy & Astrophysics 190, 342:

       o	“The constants of the lunar ephemeris ELP2000 have been adjusted to the numerical integration
              DE200/LE200 of the Jet Propulsion Laboratory.”

       o	“The semi analytical solution ELP2000 82B has been fitted to JPL numerical integrations 
              DE200/LE200… The constants of  the subsequent lunar ephemeris are fitted to the numerical integration.”

• Chapront & Chapront Touzé (1997), Celestial Mechanics and Dynamical Astronomy 66: 31-38,

       o	“The analytical solutions have been fitted to the JPL numerical integrations DE245 and DE403
              on the time span [1900–2010]…”

Implication for Stellarium

• Epoch < 1955.5: Historical ΔT reconstructions depend on assumed n_dot. A correction term must be applied to align ΔT with the lunar theory in use.

• Epoch ≥ 1955.5: ΔT is constrained by atomic time and modern ephemerides. Since ELP2000 82B inherits lunar secular acceleration from JPL integrations, no correction should be added even when VSOP87 / ELP2000-82B ephemerides are used

Recommendation

As mentioned in this PR, an all encompassing epoch cut-off was included in getMoonSecularAcceleration() as part of the effort to revise the JPL Horizons ΔT algorithm:

• Apply the correction only for epochs earlier than 1955.5
• Force the correction to zero for epochs ≥1955.5.

This change prevents double counting lunar secular acceleration in the atomic era and aligns Stellarium’s ΔT handling with the documented construction of ELP2000 82B and modern ephemerides.

Note: For pre-1955 algorithms that extend their predictions beyond the atomic era, such as Schoch (1931), Clemence (1948), and IAU (1952), it is also recommended to apply the cut-off at 1955.5 to avoid double accounting. A note may be added to alert the user that these algorithms are providing predictions in modern time based on old theory, and using these algorithms is not recommended to computing ΔT in modern time.

The current code for getMoonSecularAcceleration() clearly allows a correction post 1955.5, and this should not be the case based on my understanding.

double getMoonSecularAcceleration(const double jDay, const double nd, const bool useDE4xx)
{
int year, month, day;
getDateFromJulianDay(jDay, &year, &month, &day);

const double t = (yearFraction(year, month, day)-1955.5)/100.0;
// n.dot for secular acceleration of the Moon in ELP2000-82B
// has value -23.8946 "/cy/cy (or -25.8 for DE43x usage)
const double ephND = (useDE4xx ? -25.8 : -23.8946);
return -0.91072 * (ephND + qAbs(nd))*t*t;

}

[ssimard2504]

@gzotti ... IIRC we activate JPL DE* ΔT when DE* is used, not the other way.

Do you mean that It would be required to 'force' the selection of the JPL Horizons ΔT algorithm in the Configuration --> Time panel whenever a user select one of the DE4* Ephemeris settings in the Configuration --> Main panel ?

Currently there is no such link in the code. A user could select the JPL Horizons ΔT algorithm with any selectable Ephemeris setting: DE4* as well as the VSOP87/ELP2000-82B.

In a sense the actual code allows all possible combinations and it falls on the user to pick the 'right' combination, that is the one that makes sense... which is actually what you wrote above.

Personally I would keep the code as is, as it offers a lot of flexibility. However we may want to made clear in the Stellarium User Guide that some combinations make more sense than others. My 5 cents.

[gzotti]

Do you mean that It would be required to 'force' the selection of the JPL Horizons ΔT algorithm in the Configuration --> Time panel whenever a user select one of the DE4* Ephemeris settings in the Configuration --> Main panel ?

I think I have seen such note, i.e., when DE4* is in use, JPL DE4* ΔT is used. When VSOP87 is used, users are free to choose whatever is available (including JPL DE4* ΔT). But please @alex-w correct me. The ΔT code was mostly not mine in design, and I have not studied this part of the code in the last several years (despite some odd observations), and won't have time for it in December.

[alex-w]

I think I have seen such note, i.e., when DE4* is in use, JPL DE4* ΔT is used. When VSOP87 is used, users are free to choose whatever is available (including JPL DE4* ΔT). But please @alex-w correct me.

No, we use selected ΔT for any ephemerides theory

[alex-w]

I think the directory erfa_201 should be named erfa and this directory should be used when erfa library/headers is not installed in system (like zlib or qtcompress).

[gzotti]

please add a newline here.

[ssimard2504]

@alex-w ..I think the directory erfa_201 should be named erfa and this directory should be used when erfa library/headers is not installed in system (like zlib or qtcompress)...

I could easily take the action to rename erfa_201 to erfa. However for the second request, is it an action on me or someone else ?

If on me I could modify the section related to ERFA in the CMakeLists.txt file located in stellarium/src/external

From:

########## ERFA library (Essential Routines for Fundamental Astronomy, version 2.0.1) ##########
add_subdirectory(erfa_201)

To something like this...

########## ERFA library (Essential Routines for Fundamental Astronomy, version 2.0.1) ##########
find_package(ERFA 2.0 QUIET)

if(ERFA_FOUND)
message(STATUS "Using system-provided ERFA at ${ERFA_LIBRARIES}")
add_library(erfa UNKNOWN IMPORTED GLOBAL)
set_target_properties(erfa PROPERTIES
IMPORTED_LOCATION "${ERFA_LIBRARIES}"
INTERFACE_INCLUDE_DIRECTORIES "${ERFA_INCLUDE_DIRS}")
else()
message(STATUS "System ERFA not found, using bundled version")
add_subdirectory(erfa)
endif()

BUT there might be other changes in other CMakeLists.txt that might be needed of which I am not aware of. Moreover is find_package(ERFA 2.0 QUIET) the proper way to search for it in the system ?

I am no expert in CMake... just mainly relying on Copilot and what other CMakeLists.txt files in Stellarium are teaching me... please provide guidance.

[ssimard2504]

I decided to try out a revised version of CMakeLists.txt located in the /src/external folder based on the suggested code of Copilot. Refer to commit 492cbae for details. It works on my Windows system, because I do not have an ERFA package installed, so Visual Studio 2026 just build the erfa.lib from the *.c and *.h files provided. I have no idea if this will work on a Linux or macOS when a package is already installed.

My following commit should be my input to the Stellarium User Guide.

[ssimard2504]

@gzotti Please review my input to the Stellarium User Guide in relation to the revised JPL Horizons algorithm as per commit 43d25e2.

IMPORATNT NOTE: I have not touched section F.9 of the User Guide. I assume that one of you has developed some scripts to get all these RA/Dec and Delta-T values in this section, an effort I cannot undertake by myself.