-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add BIGMUDI model loader #8
base: master
Are you sure you want to change the base?
Conversation
Hi Felix, Thank you for your contribution to ChaosMagPy. I will take a look at your implementations and come up with some feedback as soon as I can. All the best. |
name = os.path.splitext(os.path.basename(filepath))[0] | ||
|
||
data = np.loadtxt(filepath) | ||
nmax = np.int64(-1 + np.sqrt(4 + data.shape[1]-1)) #(nmax^2 + 2nmax - (data.shape[1]-1) = 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unsure if I correctly understand the format of the Gauss coefficients in the file, but shouldn't the total number of coefficients be nmax^2 + 3nmax
? In that case, nmax
can be computed with np.sqrt(9/4 + N) - 3/2
, where N
is the number of coefficients. For the file on the website, which contains 88 coefficient entries on each line, this works out to be nmax=8
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I forgot about the h_0^l
coefficients stored in the BIGMUDI format. Rounded to integer it was giving the same answer.
I have also been comparing F from the ChaosMagPy model with the website's output (latitude 35 deg and longitude 141 deg). There seems to be a slight discrepancy of <0.2 muT, which I don't think can be attributed to rounding errors. This is especially the case between years -1000 and 0. The difference could be related to the use of cubic B-splines during the model estimation. |
I see, I guess I didn't check BIGMUDI4k.1. The error seems to be slightly smaller for BIGMUDIh.1. I'll try to figure out if these are cubic spline coefficients. |
I don't think the coefficients are for cubic splines. I guess the difference in the plot is because the model values provided on the website are produced by evaluating cubic B-splines. In contrast, we can only linearly interpolate the snapshot SH models. The difference is small so that we could stick to this solution. Otherwise, we would need the actual breakpoints used during the construction of the models. |
Yes I've been in touch with Patrick Arneitz and he told me these are evaluations of the model. He also sent me the actual spline coefficients. Perhaps I can make a version that is able to handle both the evaluations given on the website and the spline coefficients. I will come back to all of this when I have time. |
Hi Clemens,
I added a function to load in the BIGMUDI models of Patrick Arneitz and colleagues (https://cobs.zamg.ac.at/gsa/index.php/en/models-and-databases/historical-geomagnetic-field).
When I evaluate the model and compare with the tool to evaluate the model from their website they seem to agree to the precision given by the website (1e-2 nT).
I believe the coefficients provided are not cubic B-Spline coefficients, despite the fact that the models are apparently created using degree 3 (Arneitz et al. 2019), but it is not clear from the website or the data.
Perhaps you would like to check the correctness of what I've implemented. There is some complicated-looking reordering of coefficients in the code, due to the way the coefficients are stored for the BIGMUDI models.
If necessary, I can also get in touch with Patrick Arneitz for help.
Cheers,
Felix