I was trying to clear some space on my Windows computer and found the following folder C:\Users\matthewt.gmt\sessions which contains >8Gb of folders such as “gmt_session.20432”. I assume these were records of each session I’ve run in PyGMT or GMT. Are they necessary to keep? What is their purpose? If they aren’t necessary, is there someway to disable to automatic build up of them?
Thanks in advance,
Matt
That is odd. GMT normally deletes the session subduers when a session completes. In PyGMT I think that is after each module run. So either something is crashing all the time or there is a problem we would need to look into. For the command line GMT we run gmt clear sessions. Not sure if there is a pyGMT equivalent - others can comment on this.
You can certainly delete the entire session directory and its contents. Then run a very simple pyGMT command and examine if it leave behind a subdirectories.
Thanks for the quick reply. I just deleted everything, ran a pyGMT script, and another folder was created. I’m not too worried, for now I’ll just occasionally clear out that folder.
Pity that you had no time to tell us what was inside that directory that took 8 GB. That is most strange. Every time a modern script is run (and PyGMT always uses modern mode) a temporary dir is created under cache and there is no way to disable it. And, although it hosts a certain number of temporary files, the only potentially big one is the postscript file. But no way it is conceivable that it can go, not even by far, to 8 GB.
Yeah, I should have looked before deleting. Looking at the folder created yesterday after running a simple figure script, the folder create in /session is 116 KB, and 110KB of that is “gmt_1.ps-”. If this was a much more complicated figure and guess each file could start adding up.
Maybe @weiji14 can weigh in, but I’m guessing this has something to do with my gswin issue, similar to this: https://github.com/GenericMappingTools/pygmt/issues/829.
To fix the gswin issue earlier I downloaded a gswin.exe and that seemed to fix most issues, but still every time I use fig.show() I get the following error message, but figures still appear fine:
“psconvert [ERROR]: Registry registered C:\Program Files (x86)\GPLGS\gswin32c.exe does not exist. Resorting to the one provided in GMT.”
I’ll be out of communication for the next ~2months so sorry if I don’t reply. Cheers!
I have the same issue. On my windows PC (with GMT 6.3) I have 73 folders (and 465 files) with a total size of 3.2 GB. Some are named gmt_session_number and other gmt6_number. I haven’t delete them.
Can you check when is the oldest folder? Also, I assume these only have PostScript files and possiblly gmt.conf|history stuff? Clearly, the removal of these is failing for some on Windows, but not for @Joaquim on Windows?
The gmt6 files are from Nov-2019 to Jul-2020. The gmt_sessions files are from this year (July to Nov).
The files are gmt.* (.canvas .conf .cpt .frame .history .layers.0 .session) which do not exceed 2 KB.
Also there some *.ps- files of some 10- or 100- KB. Rarely a found some bigger eps. There is sometimes some .eps or ps- of some MB. There sr one of 548 MB!! Probably something that went wrong.
Joaquim uses Julia. And with the Julia wrapper one can almost forget about modern vs classic mode since classic on Julia is almost like modern on CLI. But besides that, GMT.jl when it starts automatically cleans sessions files older then a couple of hours.
True, but since you are skilled in debugging, might you find a clue as to why the the gmt_manage_workflow call in end.c does not do what we tell it to?
I think those are leftovers files of cases when the script was interrupted before ending and at that time the automatic cleaning for these situations was not working. The sessions dir is now always clean.
I have been hesitant to add an auto cleaning as I currently have a GMT process that has run for 5 weeks…
But, I think the solution to this is to find the list of PID embedded in those directories and see if such a process exists (via getpgid) and if no such process then we delete that dir. That should be foolproof and could be done by gmt end.