LonelyCat124

> For GOcean kernels we know more, thanks to the metadata and API rules. However, is the problem that you've lowered the Kernel call to a Call and no longer...

If we attempted this and failed (for good reasons) then maybe a generic equality operator on symbols and symbol_tables (especially since symbols need to be hashable I think?) is not...

I double checked and that seemed to be what I find. I think you might be correct that this is not technically valid fortran but compilers seem to be ok...

Hmm, perhaps this file isn't used, i explored a little and doing `make read_schema_spectrum_90.o` does cause the compiler to fall over on this file. Do you know who might be...

@rupertford I have had a quick look, and I think perhaps it might be to do with `INCLUDE` statements - I will check the other failing files all contain them...

I've had to change something in fparser2.py now as well - the default behaviour is now that the purity of a subroutine is None (i.e. unknown) unless it is specified....

Also I realise that this doesn't technically fix the stuff for the issue 2156 but just andy's comments within.

@arporter @sergisiso Should we also ask to test this branch with NEMO before the NEMO party?

@arporter changes done so should be ready for another look once the runner on glados is up and running again.

> Thanks @LonelyCat124 to implement this, looking at NEMO upstream it seems that they all are elemental functions, I think it will work with your implementation but it would be...