-
Notifications
You must be signed in to change notification settings - Fork 1
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
Cross validation Spider / Aragog #309
Comments
Hi @timlichtenberg @lsoucasse @nichollsh, I run the exact same simulation as here, but with interior model=SPIDER. With those conditions the planet reached the global energy balance. Besides the time-stepping factor mentioned #193, the rheological front when using Aragog starts above the CMB, so I'm a bit confused about it, as we are using the same melting curves, just in the P-T space. On the other side, both of them finish around the same time. We can discuss further about this, in the meantime I will check from the Aragog which parameter is causing the behaviour in the first 80 GPa. |
I copy the images from the Aragog run from #306 (comment) to here in this thread again. It looks to me as if the Aragog simulation is not initialised on an adiabat. From 80 GPa downwards the temperature profile is isothermal already at the first timestep. We need to understand the reason for this, possibly the initialisation is not yet working correctly? |
Could you send us the corresponding Aragog input file @planetmariana ? |
@lsoucasse is the input file Aragog.toml in main, I just change the interior model as SPIDER or Aragog, using both with JANUS. Both simulations took around 12hr, so for now I'm checking from Aragog which parameter can be changed. As discussed before @timlichtenberg if I change rheological_transition_melt_fraction there's a difference, but I don't know how unphysical that can be. See below: Output from Aragog with rheological_transition_melt_fraction=0.4 : Output from Aragog with rheological_transition_melt_fraction=0.2 |
0.4 is good and can stay. The latter is output from only running Aragog directly, and the former is using PROTEUS to execute Aragog, right? In the latter plot (just Aragog) the temperature profile looks adiabatic, it's only that the initial temperature is not high enough to generate a fully molten planet. This could mean that something is not properly communicated from PROTEUS to Aragog. |
Yes, these last ones are outputs directly from Aragog. Ok, I see the problem. I will check then outputs/inputs from both sides to see where's the difference. |
Hi @timlichtenberg @lsoucasse @djbower, I changed the initial config file for both SPIDER and Aragog for prescribed heat flux at the surface 1e6 and 0.0 at the inner boundary and the same end_time (500). I over plotted the liquidus to be sure that the initial profile was super-liquidus and also plotted the heat fluxes in Log scale. The convective and conductive heat fluxes are still very different, but if you take a look to the thermal profile of Aragog at t=500 around 100GPa is showing the same behaviour as we discussed previously in this discussion: here, even with the initial temperature file 0.json from SPIDER. SPIDER Aragog Also, I noticed that this line from output.py:
Is not being executed, ie. is not plotting the solidus and liquidus (I did it manually), but it's also not raising an AttributeError, unless I call |
This doesn not look too bad for me, nice! :) First, the system is now cooling, check! This is different than in the linked thread, in there the system was initially isothermal and then heated up at the bottom and cooled at the top. The behaviour of this plot here is quite different (which is good)! SPIDER and Aragog follow a somewhat different (but both overall reasonable) cooling path and the thermal gradient of Aragog seems to follow a somewhat different behaviour, which could be correct given the convective fluxes. We cannot quite tell, however. First, you are plotting different init time steps it seems to me (after 1 yr for SPIDER, 0 yr for Aragog). This means we cannot compare the actual convective flux. Then the cooling path is hard to follow, as we only have 2 time steps overall. Can you please add to the plots:
|
@timlichtenberg Sure ! Discussing with @lsoucasse I was wondering why Aragog take the initial temperature field and then warms to consequently gets cooler, it's following the melting curves correctly, but still a bit curious. Also, it's visible the difference in order of magnitud still on the convective heat flux as it evolves. And, the melt fraction at the lower boundary has a jump but I think that can be related to the limits I set to all the lookup tables (up to 135GPa). In any case, we realised that the problem with the liquidus being set before the pressure it's only affecting the plotting part and not the evaluation of other properties. SPIDER |
Hi @timlichtenberg @lsoucasse , I was testing Aragog with the init_temperature= adiabat from SPIDER, with the parameters of surface_temperature and basal_temperature, just to check that Aragog was not getting confused on using the init_temperature or the fixed temperatures. In this case I put the upper and lower values from the temperature field and the temperature field itself, realising that after timestep 0 the adiabatic warms and then gets cooler as I mentioned to you before. I tried to set an end_time=1e6, but the simulation finish at 1e3, so I set a statement for debugging, where I obtained this:
Then, I was reading that can be related to the way that the solver is managing rapidly changing derivatives. In any case, I tried also with an initial temperature field isothermal, obtaining exactly the same error, but very small changes in time (1e-27): I will keep printing debugging logs from the solver to check if it's the method itself of the the grid resolution that is affecting the whole process :) |
Thanks! Can you attach the used config files for these runs please? |
Hi @timlichtenberg @lsoucasse, I did the comparison between Aragog and SPIDER with:
I produce this two movies to see the evolution more in detail but overall they seem to behave similarly. Although, right now I'm running new simulations with: core cooling condition and fixed heat flux at the upper boundary and higher resolution but it's taking a bit long, so I will try to run them in the cluster. Aragog: SPIDER |
Awesome, thanks for the update! After our discussion yesterday, we settled on now doing the comparison for convective- and conductive-flux only with Aragog and SPIDER to see how the codes compare with only the exact same flux terms operating. In addition, we are trying to smoothen the usage of Aragog within PROTEUS; for that we want to run PROTEUS with default settings (as discussed yesterday) and compare it by simply switching out Aragog vs. SPIDER, with settings as close as possible to each other. |
I have tried to run the default settings with Aragog (and Janus) but it is extremely slow. |
Hi @lsoucasse , yes when using Aragog+JANUS it can take up to 8hr with default settings. |
Can you do a comparison with AGNI? |
I tried with AGNI but it fails to converge and provide a solution with default settings. Here is the log. |
AGNI also seems to be performing very slowly for you. In one of the PROTEUS steps, it only manages a single iteration before timing-out. |
Which points to a SOCRATES issue. I also noticed that sometimes SOCRATES was returning garbage values in the GitHub actions. I don't think this is a fault of gfortran, but it points to a problem with the spectral files. The files themselves have not changed, so my suspicion is that OSF could be providing corrupted data... |
I notice that the volatile settings are somewhat extreme in the .toml file. I cannot find |
On this note, I should add that AGNI will not perform well when getting down to Earth-like surface temperatures. It will probably try to rain-out a large fraction of the atmosphere, since the outgassing will generate a massive amount of steam. |
It's probably okay to stop at mantle solidification for the demo, but that should be followed up I guess. |
We have now Aragog running, using look up table and producing reasonable output.
But we now need a comparison with Spider to validate the implementation, see first results from @planetmariana here.
The text was updated successfully, but these errors were encountered: