optimizing runtime with n_pg_min and n_pg_max

Suggestions for improvements, new features, etc.
Post Reply
Posts: 88
Joined: Sun Jun 16, 2013 11:31 am

optimizing runtime with n_pg_min and n_pg_max

Post by ehsan » Mon Sep 05, 2016 2:04 am

Dear Rich,

I am granted some computing time on a supercomputer where I want to spend it on my GYRE calculations. Thus, the more optimal my runtimes are, the better I use my computation grant.
To this end, I've been trying to optimise the inlists, so that for nonradial modes, it sticks to the frequencies with radial order, n_pg between a reasonable upper and lower values. Most importantly, the high-order g-mode require most of the computation time, since with a slight decrease in scanning frequency, a large number of them fall inside the scanning range; this gets even worse with rotation, when using TAR for prograde modes. Please, recall our recent paper on KIC 7760680, where observed modes reached n_pg = -53 (for the best model).

In such circumstances, n_pg_min and n_pg_max "could" come to the rescue, by ensuring that the trial frequencies are scanned so that no time is spent on high-order g-modes exceeding |n_pg_min|; n_pg_max has quite smaller effect since low-order p/g modes are sparse in frequency space.

Currently, specifying e.g. n_pg_min only limits the printout of the modes. E.g. if the freq_min is a small number, g-modes with |n_pg| > |n_pg_min| are computed, and the time is spent, while they are just not dumped to the output file. This is natural, since, I "guess" that the default scanning frequency direction is from the lowest to the highest.
I propose to elaborate this a step further:

If n_pg_min is specified by the user, then the direction of frequency scanning would better be from largest to lowest. If n_pg_max is specified, the frequency scanning must be done from lowest to highest. If both are specified, the scanning can be carried out from some anchor/middle point in between the specified range, an be split into two directions: step one going from freq_middle upward until we hit n_pg_max, and step two going from freq_middle downward until we hit n_pg_min.
A simple sort algorithm can later put them in increasing freq and/or n_pg order for the write out.

Such a simple approach ensures that optimal amount of time is spent on computing modes that are needed, not less than that, and not more.

Kind regards,

Post Reply