GUI: Particles Should Not always_refresh if N>10^X

[ax3l]

We often use the slider to get a preview on large 3D data sets.

Unfortunately, the defaults for the GUI are to "Always refresh" for both fields and particles. This means that if we are opening a large data file this will hang forever even in step zero.

Can we add a quick check for the number of particles (.shape) in the first species that is default selected? If this number is larger than, e.g. 10^9, let us not put a default on the "Always refresh" button.

cc @n01r @PrometheusPi @kossag14 @BeyondEspresso

[RemiLehe]

Yes, I agree that this would be useful.

However, using the shape of the first particle at the first iteration might not be representative. (e.g. the species might be empty at the first iteration if we have a moving window, or in the case of ionization, the first species might be the target species of an ionization module, and so it might be empty while other species have larger number of particles.)

Therefore, I wonder if an alternative option would be to allowing the user to set the always_refresh to False for particles by default, for all sliders, for instance through a similar system as matplotlib's rcParams, i.e. this could be set at the beginning of the notebook, or in a default configuration file.

Of course, this kind of parameter setting could also define other defaults, such as the colormap, etc.

@ax3l @PrometheusPi @hightower8083 @MaxThevenet @soerenjalas Any opinion?

[hightower8083]

I agree, that default always_refresh can be annoying especially for the cases with a lots of particles (e.g. no output selection). Having an option to inverse it, either as sliders key_arg, or by setting some param in a header is a good and straightforward solution.

From my side, I've an additional suggestion related to the subject. When plotting the particles, the change of the colormap and vmax does not require the histogram recalculation, but presently one cannot avoid it. So, for example, when I want to scrutinise the features of the phase distribution (e.g. z-uz), I tune the vmax and switch between colormaps with higher/lower contrast -- during this procedure the histogram does not need to be refresed, but only the plot itself.
Do you think that the 'refresh' function can be optimised in this way, e.g. by adding some check of 'what is changed' and choosing if to re-use the calculated data?

UPD: I also believe, that adding the 'what is changed' check could boost the field plotter use, by avoiding unnecessary the disk operations in cases when one tweaks with xlim, ylim, vmin-vmax etc

[ax3l]

I think an option would definitely work as well.

As far as I understand it, rc files are just another way to set options and would be an orthogonal feature for any (default) parameter we set in interfaces. They are analogous to /etc vs. $HOME config files vs. environment vars vs. parameters with the typical precedence order.

@hightower8083 that's a good point and can be handled if one reworks (deepens) the update events of the GUI. can you document the colormap point in a separate issue please? Chaning representation after data load is a typical task indeed. For the axis ranges, be aware you can already change them interactively.

[hightower8083]

@ax3l yep, I know that with this new notebook interface one can scale/move the images inline (which before was only with QT/WX).

My concern was indeed mainly to enable picking vmin/vmax and cmap without re-reading/re-calculating the data. In a plotter I've developed for PICLS code many years ago I've used such an option (it was tkInter GUI at that time), cause there we used to read and stack a huge number of ascii files, and it was crucial..

I'll create another issue for this.