UoB Optimisation (Work in progress) #95
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…my module in order that we can correctly calculate rrsun using the true anomaly rather than the mean anomaly. Have also added multiplication by rrsun to two-stream-grey-rad, which makes no difference to results in initial tests when ecc = 0.0
…ue anomaly, and therefore be able to do mars time-telling.
… expects orbital_period in seconds, but I had supplied it in days. This is because Alex's code expects it in days. Will fix Alex code to make it consistent.
…e of surface optical depths and albedos, assuming transparancy in the visible. Useful for working out rough values for optical depths and albedos for a simple mars model.
…ay is not the same as one mars day. Have altered rotation rate and orbital rate such that each can be set as an integer, and we end up with a length of sol which is also an integer. This can then be used as the averaging period.
…dependently. Then also only calculating rh when rh is asked for. Model now runs and looks vaguely mars-like, but dates of equinox etc still not right.
…nml, and ability to use specified temperatures for evaporation calculations in surface flux. This means that, when using a dry model where temperatures are outside standard range for sat specific humidity calculations, then false temps can be used to stop it failing.
…xis. For some reason, the interpolator will get rid of such variables when used on its own, so I modified the python to add them back.
Conflicts: src/atmos_param/two_stream_gray_rad/two_stream_gray_rad.F90
Adding Bristol BC4 setup from master into mars_dev branch from Stephen
…c-of-day using just the seconds part of the get-time command. This is fine if solar day length is less than earth day length, or comparable, as is the case for mars. But for longer days than 86400, this is a problem, as frac-of-day is unaware of all the time being put into the days variable, and so frac of day is always small, meaning that on titan the sub-stellar point is fixed in longitude. Have copied the way this is done in rrtm and socrates, and this has fixed the problem. Will probably help Mars simulations too.
…b_fftw Conflicts: src/extra/env/bristol-bc4-gfortran src/extra/python/isca/templates/compile.sh src/extra/python/isca/templates/mkmf.template.ia64
|
Hi George,
That’s great! And using FFTW instead of the old FFTs is something I’ve long wished for. Does this, or could it in future, allow parallelisation in the zonal direction also? In any case, it is certainly an improvement. We'd love to read your thesis whenever it is ready — congratulations on that and on your work.
As regards how best to merge your changes, we’ll need to discuss this and get back to you. We also may need to discuss this with you offline, so if you wouldn’t mind sending an email address that would help. (I see one at brighton.ac.uk , but that may be out of date.?)
Geoff
|
|
Hi Geoff, Thanks! I have been using the serial version of FFTW, however it would be trivial to plug in the MPI/OpenMP version instead. Yes, that email address is out of date. I've found your exeter.ac.uk email address, so I'll shoot you an email to discuss this further. Cheers |
|
Thanks very much for this George. Looks like really excellent work. Certainly very keen to read your thesis once it's available. As you say, the |
|
Brilliant, thanks Stephen! I'm still proof reading at the moment, but the document will be finished by the 9th of September at the latest. Let me know when you've decided how best to proceed. |
dennissergeev
added
infrastructure
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi all,
I have been working on my MSc thesis in computer science over the summer, entitled 'Porting and optimisting the Isca climate model on Intel and Arm processors'. This project involved porting, bechmarking and optimising Isca on a few different HPC systems including BlueCrystal phase 3 at Bristol, Blue Pebble at Bristol, and the Isambard supercomputer as part of the GW4 alliance. I am currently proof reading my thesis, however I can make it public to you if it is something you would be interested in reading.
One of the optimisations I have made is to use the FFTW library rather than the bespoke FFT supplied with the FMS that was written in 1981. This change has improved the performance of the code!
I have mostly been working from the Grey Mars branch, which doesn't appear to have been merged with the master branch yet. However, I can merge only my changes if required, as they do not depend on any of the code in the Grey Mars branch. Please let me know how best to merge my changes.
Many thanks,
George