PvlObject::addLogGroup deprecation message

[lwellerastro]

ISIS version(s) affected: isis8.1.0-RC2

Description
Maybe not a bug, but definitely a nuisance. I have noticed that some programs I use (cnetedit, pointreg) send the following message to standard output:

This function(PvlObject::addLogGroup) will be depreciated in ISIS3 v9.0 in favor of Application::appendLogGroup

I don't know what this even means from the user perspective, but the number of times it is displayed for some programs (pointreg in particular) is excessive and contributes to bloating of cluster standard output files. Is this a debug statement that has been left on at some high level? Is there a way to turn it off at the user end?

Some programs only show the message once, but for some reason pointreg is displaying it 8 times.

Just wondering how to keep from capturing this in my cluster files and if it's something I need to be aware of at the user level. Thanks.

[acpaquette]

@lwellerastro This is from following the deprecation process outlined here:

https://github.com/DOI-USGS/ISIS3/wiki/Deprecation

In it we define that a deprecation warning has to be used to the user.

When this specific warning was being added I thought it might be excessive but was curious to see the response.

A good way to avoid it would be to direct the output from apps into files, the error should still print to the terminal but not be present in the file. So something like:

cnetedit arg1=something arg2=somethingelse >> cnet_edit.txt

[lwellerastro]

Thanks @acpaquette, but I'm already doing something similar by specifying a specific print file (via -log=myprint.prt) in the command line. That is not the problem though, it's the standard output file from SLURM that is capturing everything and I'm not willing to not create that file as it often contains important information about the cluster job not captured anywhere else (plus there are some isis programs that have info that only prints to screen but is not captured in the print.prt for some reason). So it sounds like I am stuck with this particular error until v9.0 comes out.

It seems like it's a programming specific message, so why display it to the user at runtime? I read #5310 and it honestly doesn't mean anything to me. How will the user by affected by this if at all? And why does pointreg display it so many times?

[acpaquette]

For SLURM, you should be able to direct the stderr output to a different file. It seems like the following would do the trick:

#SBATCH -e slurm-%j.err
#SBATCH -o slurm-%j.out

Generally speaking, I agree that in this case the message is only useful/informative at a programmatic level. I don't know of a good way to display the error to a programmer without also displaying it to the user. In some instances we want users to see messages rather than developers and we would likely do this in the same fashion.

I think this could be a useful discussion for the software team in restructuring how we deprecate functionality.

[lwellerastro]

yup, I know. I'm just saying with many, many thousands of images and processes getting this messages the slurm output files are getting bloated and taking up space. Was honestly just wondering if it was an oversite having it go to screen all of the time and if it was going to be a new functionality that as i user I would need to make adjustments for. I'll try my best to ignore it until until v9.0 comes out =)

@acpaquette, I appreciate you thinking about how I can avoid it or capture it differently though. Thank you.

I think from a purely user perspective, if a program is going to be deprecated, then it 100% makes sense to know about it at runtime before the change takes place. But for for code specific deprications, I don't need to know unless they affect output or functionality in some way. But I do see where you're coming from in tring to manage messages for users vs developers and at the moment I don't have a good recommendation other than separately which may not be ideal for you all.