Problem

Lightkurve has a lot of unit tests which access the data archive at MAST. This causes a number of problems:

• our tests are slow;
• many of our tests require internet access;
• tests sometimes fail due to intermittent issues at MAST rather than Lightkurve issues;
• we add an unnecessary load on MAST's services.

Current workaround

We have flagged the tests which require inte

Can we use a value of center that is outside of the domain? E.g. if we want to model a shell with a pointmass, can the value of center be at the origin, but ymin be at some large positive value?

The python implementation of leapfrog does not make use of the fact that drifts can be combined when not storing output, causing it to be slower than necessary. Comparing to the C implementation, it also appears to not be as precise.

Throughout the tardis codebase, we have multiple LATEX strings which are written as simple strings - they should be converted to raw strings so that we don't need to write double \\.

For e.g.:
https://github.com/tardis-sn/tardis/blob/e8ab6605d91b69d389a16802be8e06f8ef0cc51a/tardis/plasma/properties/general.py#L40-L42

latex_name = (r'g_{\textrm{electron}}',) 
latex_formula = (r'\Big(\d

There are way to many UserWarnings coming out of the testing suite (causing at least one of the travis jobs to terminate). Ideally the tests should avoid running into those issues except in the case when their raising is tested on a context manager.

I suppose this issue can be a nice starting point for someone new to the project and wanting to become familiar with the code base before e.g. GSoC

Error spotted by @stephanedelperugia

Context

~/.radis

[DB_ISSUE_78]
info = ... 
path =
        PATH/TO/cdsd_hitemp_07
format = cdsd-hitemp
levelsfmt = radis

Note that parfuncfmt is not declared

Minimal Code

s = calc_spectrum(2000, 2300,         # cm-1
                  molecule='CO2',
                  isotope='1,2,3',
                  pressure=1.01325,   #

Adstring outputs the wrong string when dec starts with negative zero (i.e. -0.5), while radec converts correctly.

>> adstring(15, -0.5)
" 01 00 00.0  +00 30 00"

>> radec(15, -0.5)
(1.0, 0.0, 0.0, -0.0, 30.0, 0.0)

The bug seems to be this line in adstring.jl:

dec_string = @sprintf("%+03.2d %02d %s", dec_deg, dec_min, dec_sec_string)

which ignores the negative zero.
A