Configuring QuPath resouce consumption for shared computing enviroments?

I’m in the process of installing QuPath for researchers on a shared system, where the many other processes are active.

Is there an external way to pass usage limitation to the program, such as a Config file, env variable,
or CLI argument that can be addressed in an automatic (and dynamic startup way)?


(If this post is misplaced, relocation assistance would be appreciated)

The system particulars are primarily derived GridEngine. Which allocates resources based on submitted requests, to a node (basically a computer server) wherein the hardware spec’s and usage are visible to the program (thus autodetect cores or mem creates issues as), and GridEngine will terminate any usage that exceeds the requested values.

I don’t have experience of this myself, but when using the standard launcher the maximum memory can be set inside the .cfg file with the -Xmx option, mentioned in the last line at

There is a little bit of (old) info about running QuPath from the command line here, which may allow you to pass the limit directly. Although running QuPath from the command line is something that certainly needs revisited one day…

Awesome, (I did not see that earlier)
That will take the ‘standard’ & ‘non-standard’ java options and pass them to the JVM?
-Xmx, -Xss should cover our core case.

Seems I spoke too soon, I’m not sure what I’m missing …

in a freshly untar’d Qupath 1.2
in QuPath/app/QuPath.cfg I edit in


I then launch it from the command-line and see.

which matches the auto detect fraction at 1/8th total RAM

Thanks again

Curious… how do you launch from the command line?

Though if if I change it from within the GUI it does seem to preserve the setting within a users space but if I open with a second user account it starts over again. (a reasonable separation, but unusable for setting global defaults.)

here is some copy and paste for how I’m launching

QuPath  QuPath-0.1.2.tar.gz
[jpessin@scc5 build-playgroud]$ whereis QuPath
QuPath: /projectnb/scv/jpessin/build-playgroud/QuPath
[jpessin@scc5 build-playgroud]$ cd QuPath/
[jpessin@scc5 QuPath]$ pwd
[jpessin@scc5 QuPath]$ ls
QuPath  app  runtime
[jpessin@scc5 QuPath]$ QuPath
17:17:54.228 [main] [INFO ] qupath.QuPath - Launching QuPath with args:
17:17:54.898 [JavaFX Application Thread] [INFO ] qupath.lib.gui.prefs.PathPrefs - Locale FORMAT set to en_US
17:17:54.902 [JavaFX Application Thread] [INFO ] qupath.lib.gui.prefs.PathPrefs - Locale DISPLAY set to en_US
17:17:54.925 [JavaFX Application Thread] [INFO ] qupath.lib.gui.prefs.PathPrefs - Tile cache size: 3641.00 MB
17:18:01.452 [JavaFX Application Thread] [INFO ] qupath.lib.gui.QuPathGUI - Selected style: Modena Light
17:18:01.453 [JavaFX Application Thread] [INFO ] qupath.lib.gui.QuPathGUI - Performing update check...
17:18:01.453 [JavaFX Application Thread] [INFO ] qupath.lib.gui.QuPathApp - Starting QuPath with parameters: []
17:18:23.601 [JavaFX Application Thread] [INFO ] qupath.lib.gui.QuPathGUI - Calling Platform.exit();






I did also try:
$ QuPath -Xmx4G
but this just becomes
. . . Starting QuPath with parameters: [-Xmx4G]
. . .
Unable to open -Xmx4G with OpenSlide: -Xmx4G
which I’m guessing is expected behaviour?

Ah yes, that’s true for v0.1.2 - preferences are stored on a per-user basis, presumably including the max memory setting. However in v0.2.0 that won’t be/isn’t possible for the memory setting, since JDK 8 handles this differently through javapackager, which isn’t available in later versions. The only way I’ve found around that in v0.2.0 is for QuPath to write its own memory setting to the .cfg file (which seems to work, but I can image it may suffer permissions problems at some point if a full installer is used…).

Anyhow, there is a bit more about the command line here. The format should be something like

java -jar QuPathApp.jar /path/to/image/or/qpdata/file -script /path/to/script

You should then be able to add Xmx4G there (and skip the image/qpdata file and script). I believe this will also bypass the normal launcher and its application of memory settings.

If this looks promising, the next challenge is likely to be ensuring that -Djava.library.path is set appropriately so that OpenSlide works and/or Bio-Formats + the Bio-Formats extension are found on the classpath. One approach for OpenSlide could be to ensure the current working directory is the one containing the native libraries associated with QuPath when it is launched.