FTheoryTools: Use Zenodo data as artifact

[HereAround]

The tar ball provided at https://zenodo.org/records/14611045 (version 2) can be downloaded. It contains two .mrdi files, which are the OSCAR serialization of two F-theory models. Creating these two models by loading in the .mrdi files takes about 5 to 10 minutes, each. Computing these models from scratch takes probably half an hour/3-4 hours, respectively. A stark improvement, that we must use.

@benlorenz The tar ball at zenodo is about 400MB in size. I would love to add a test for this artifact/creating the model. However, it seems to me, that this would burn too many resources. Any idea/suggestion?

cc @emikelsons @apturner

[codecov]

Codecov Report

Attention: Patch coverage is 20.00000% with 4 lines in your changes missing coverage. Please review.

Project coverage is 84.36%. Comparing base (264490b) to head (bd335c9).
Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
.../FTheoryTools/src/AbstractFTheoryModels/methods.jl	33.33%	2 Missing ⚠️
.../FTheoryTools/src/LiteratureModels/constructors.jl	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4423      +/-   ##
==========================================
+ Coverage   84.34%   84.36%   +0.02%     
==========================================
  Files         663      663              
  Lines       87788    87804      +16     
==========================================
+ Hits        74042    74075      +33     
+ Misses      13746    13729      -17     

Files with missing lines	Coverage Δ
.../FTheoryTools/src/AbstractFTheoryModels/methods.jl	77.94% <33.33%> (-0.40%)	⬇️
.../FTheoryTools/src/LiteratureModels/constructors.jl	95.08% <0.00%> (+1.23%)	⬆️

... and 5 files with indirect coverage changes

[aaruni96]

@benlorenz can you check whether the new job step I added (extra-large-test, line 123) makes sense for trying to implement what you suggested during triage ?

[benlorenz]

@benlorenz can you check whether the new job step I added (extra-large-test, line 123) makes sense for trying to implement what you suggested during triage ?

Yes that was what I had in mind but I see a small issue, that this will still be run in the default group when the tests are run locally without a testset. I will do a small refactoring of these subsets and push another change in a few minutes.

[fingolfin]

A note on the serialization performance (repeating some of what I said during triage): I got the following for pure JSON parsing of the data:

julia> @time JSON.parsefile("1511-03209.mrdi");
  3.564484 seconds (77.98 M allocations: 3.459 GiB, 47.63% gc time, 0.09% compilation time)

julia> @time JSON.parsefile("1511-03209-resolved.mrdi");
 14.119739 seconds (188.79 M allocations: 9.096 GiB, 46.01% gc time)

@HereAround what are the timings on your computer?

I hope that means we have indeed a chance to get the performance for loading these -- I'd be hoping for something below a minute.

[fingolfin]

ping @antonydellavecchia

[HereAround]

A note on the serialization performance (repeating some of what I said during triage): I got the following for pure JSON parsing of the data:

julia> @time JSON.parsefile("1511-03209.mrdi");
  3.564484 seconds (77.98 M allocations: 3.459 GiB, 47.63% gc time, 0.09% compilation time)

julia> @time JSON.parsefile("1511-03209-resolved.mrdi");
 14.119739 seconds (188.79 M allocations: 9.096 GiB, 46.01% gc time)

@HereAround what are the timings on your computer?

I hope that means we have indeed a chance to get the performance for loading these -- I'd be hoping for something below a minute.

I got the following:

julia> @time JSON.parsefile("1511-03209.mrdi");
  8.901444 seconds (77.98 M allocations: 3.434 GiB, 65.55% gc time, 0.16% compilation time)

julia> @time JSON.parsefile("1511-03209-resolved.mrdi");
 65.112687 seconds (188.39 M allocations: 9.041 GiB, 88.51% gc time)

[HereAround]

I am generally speaking happy with this PR - ready for review.

[HereAround]

Thank you for your help @benlorenz and @aaruni96 !