Remove parser information from output_parameters

[mbercx]

Fixes #582

Now that aiida-core adds both the AiiDA and plugin version to the
CalcJob node attributes, as well as the parser name, it is no longer
necessary to add this information to the output_parameters dictionary.
This PR removes the get_parser_info() function that generates this
output.

The parser_warnings are also removed for the base/pw/ph parsers, since
they were not used here. We leave the parser_warnings for the neb/cp
parsers, but these should be replaced in a future PR by the use of a
logging container.

[sphuber]

Thanks @mbercx . Changes look good, I was just wondering if we really need this key parser_info at all. First thing I though was to change the content to the entry point name of the parser, which then also makes it machine readable. But then I thought that this is not necessary as this value is already stored as an attribute of the CalcJobNode itself, so we would merely be duplicating it in the output_parameters output node. I think we can just get rid of the parser info key entirely.

[mbercx]

I think we can just get rid of the parser info key entirely.

I was also considering this, and I agree! In this case the get_parser_info function only returns a dictionary with the 'parser_warnings' key, which has an empty list value. Should we still keep the function so it's easier to add other parser info in the future, or remove it and simply initialize the parser_info as {'parser_warnings': []} wherever it is called?

[sphuber]

To be honest, if you look at how the parser_info is used, you can simply just get rid of it entirely and simply declare the variable parser_warnings = [] directly. As far as I can see, this is at the end of the parser simply added as an attribute. No need to keep it as a key inside dictionary parser_info if that is the only member.

[mbercx]

I've noticed that the parser_warnings key isn't used for all calculation types. For example, for pw.x, I can't seem to find a single append to the parser_warnings list. Should I still keep the parser_warnings in the output_parameters in this case for consistency?

More generally, why do we have a list of parser_warnings in the output_parameters? Can't we just warn the user using logs.warnings.append? E.g. can't we change these lines:

aiida-quantumespresso/aiida_quantumespresso/parsers/parse_raw/neb.py

Lines 54 to 55 in 7039365

	if not finished_run: # I try to parse it as much as possible
	parser_info['parser_warnings'].append('Error while parsing the output file')

by

        if not finished_run:  # I try to parse it as much as possible
            logs.warning.append('Error while parsing the output file')

of course, after creating a logging container at the start of the method with:

logs = get_logging_container()

[sphuber]

The reason is historical. The original implementation of the parsers used parser_warnings in the output_parameters as the and the only way of communicating problems detected in the parsing of the output. This was before I added the concept of exit codes to aiida-core as the preferred way of communicating problems that should be machine readable. I kept a system for adding human readable warnings, but directed them through the logging system, as that is where human-readable messages are supposed to go. I implemented this for the PwParser, and since, some other parsers adopted this as well. To simplify its usage, the get_logging_container utility was created. We haven't gone through the exercise of updating all parsers to use this new procedure. Would be great if you are willing to do that in this PR 👍

[mbercx]

We haven't gone through the exercise of updating all parsers to use this new procedure. Would be great if you are willing to do that in this PR.

I'm happy to work on cleaning up the parsers, but going through some of these warnings, I find a lot more than just parser_warnings. Some of them also seem to errors, i.e. in the Parser.parse() method they are picked up and call the exit() method of the parser with a certain exit code. For example:

aiida-quantumespresso/aiida_quantumespresso/parsers/parse_raw/neb.py

Lines 45 to 48 in 6d4c706

	if not finished_run: # error if the job has not finished
	warning = 'QE neb run did not reach the end of the execution.'
	parser_info['parser_warnings'].append(warning)
	job_successful = False

aiida-quantumespresso/aiida_quantumespresso/parsers/neb.py

Lines 70 to 71 in 6d4c706

	if 'QE neb run did not reach the end of the execution.' in neb_out_dict['parser_warnings']:
	return self.exit(self.exit_codes.ERROR_OUTPUT_STDOUT_INCOMPLETE)

There is also the job_successful variable that probably should also be removed. It seems that these parsers could use a good scrubbing that is beyond the scope of this PR, and would make it rather massive/messy?

I'd rather split this work up for the different parsers, and familiarize myself with the output of these calculations when I work on this, so I understand better what is going wrong, i.e. understand the meaning of all the exit codes and output parameters.

For this PR, I'll just remove all the parser_warnings and replace them by proper usage of the logging container.

[sphuber]

I actually agree that doing what I proposed is beyond the scope of this PR. I wouldn't even start to introduce the logging container in the other parsers. Let's here just simply get rid of the get_parser_info util function and directly declare the parser_warnings = [] variable in the parsers where it applies. In another PR you can then actually change the behavior of the parsers to use the new logging concept

[mbercx]

I actually agree that doing what I proposed is beyond the scope of this PR. I wouldn't even start to introduce the logging container in the other parsers. Let's here just simply get rid of the get_parser_info util function and directly declare the parser_warnings = [] variable in the parsers where it applies. In another PR you can then actually change the behavior of the parsers to use the new logging concept

Yeah, after working on it a bit, I realize doing this partially also will just create more of a mess. I'll do as you suggest and open some Issues for cleaning up/use logging for the various parsers.

[sphuber]

I think you are done with the changes here, correct @mbercx ? If so I will review it

[sphuber]

Looks good to me, thanks @mbercx