Add -finit-local-zero flag on Melvin to force local var initialization

[jqyin]

Uninitialized local variables are not set to zero by default with gnu compiler
on Melvin.
Add -finit-local-zero flag so Melvin behaves similarly as other test machines
in term of local variable initialization.

[non-BFB]

[bishtgautam]

Looks good.

[worleyph]

I haven't been tracking this, but isn't the problem with having uninitialized variables (if they show up in output that then indicates a diff)? There are (or used to be) production systems and compilers that do not initialize variables to zero, and historically we have NOT used flags to set uninitialized variables to zero as this masks real errors.

[singhbalwinder]

Hi @jqyin :
It may be just my personal preference, so you can ignore my suggestion if you like. If I am understanding this change correctly, I think we should not rely on compiler options to set variables to zero. Variables should be initialized explicitly to their desired values in the source code. I have seen uninitialized variables causing issues in the past and they are hard to trace sometimes. Unless we require users to use these compiler flags (setting uninitialized variables to zero) always, I think we should fix these in the code itself. It is also hard to rely on compilers to initialize variables to zero as I have seen cases where compilers has bugs and they don't play well.

Again, fixing it in the code would require us to know which variables are uninitialized in the code, which can be hard sometimes.

[worleyph]

It may be just my personal preference, so you can ignore my suggestion if you like.

This is more than a personal preference issue. @rljacob , please weigh in. I would argue that this is a an ACME software engineering requirement - don't use compiler flags to initialize variables (unless they are initialized to NaNs or something similarly nasty).

[singhbalwinder]

This is more than a personal preference issue.

Thanks @worleyph . I agree with you. We don't allow this in the atmospheric codes and try hard to fix these issues as soon as they are discovered. I wasn't sure about the land side. I agree that this should be a standard ACME policy to not to rely on compilers to take care of uninitialized variables.

[rljacob]

Ok lets not do this.

Will Melvin continue to diff on these tests even after blessing because some variables have random stuff in them?

[jqyin]

@worleyph and @singhbalwinder , I agree that the root cause is the code that has uninitialized local variables, and non-BFB is resulted from the rounding errors of undefined initial values. Currently, these issues are presented in BGC-related land code. Since most integrators don't have access to Melvin, it took a while to even realize this is the problem.

@rljacob , if we bless the diff to let the high priority PR go in, I can try to fixes this legacy issue. Until that, I think any BGC-related code changes will likely cause diff.

I'll close this PR.

[rljacob]

Ok lets do that.