Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

convert remaining IN and OUT test codes to F90 #331

Merged
merged 9 commits into from
Mar 3, 2023
Merged

Conversation

jbathegit
Copy link
Collaborator

Fixes #308
Fixes #295

Part of #33

@jbathegit jbathegit changed the title convert remaining IN and OUT test code to F90 convert remaining IN and OUT test codes to F90 Feb 24, 2023
@jbathegit
Copy link
Collaborator Author

So I added a new outtest8.F90 test to capture some more of the library subprograms that weren't yet being tested. And I correspondingly updated the bufr-11.6.0.tgz bundle on the emcrzdm server to include the input and baseline output files for this new test.

Everything works fine when I run this locally in my own area and let it download the updated bufr-11.6.0.tgz bundle from the server. But the automated CI tests apparently don't download this bundle and instead copy it in from a stored cache, according to the Copying file /home/runner/data/bufr-11.6.0.tgz to test data directory statement in the logs. The problem is that stored cache obviously doesn't contain the baseline files that are now needed for the new outtest8.F90 test, so all of those tests are now failing.

@edwardhartnett how do we replace the old bufr-11.6.0.tgz in /home/runner/data with the new one? Until we do this, the cmake option -DTEST_FILE_DIR=/home/runner/data in all of the workflow yml files will continue to use the old cached version and these tests will continue to fail.

@jbathegit
Copy link
Collaborator Author

I know I have admin access to this repository, but I've been through all of the Settings pages and don't see any way to update the cache with the new bufr-11.6.0.tgz file.

@edwardhartnett once you're back from leave, I'd really appreciate a quick tutorial to understand how you cached that file in the first place, and how to update it (thanks ;-)

@edwardhartnett
Copy link
Contributor

OK, I didn't notice until now that you had converted the rest of the IN tests. So I have done some in another PR.

In order to invalidate the data cache in the develop branch change this line in developer.yml:

key: data-1
Change this to "data-2" and it will invalidate the current cache and fetch the data again.

! Scan for certain values across all of the data subsets in the internal arrays, and verify some of them.
call ufbtam ( r8vals, mxr8pm, mxr8lv, nsub, 'CLAT CLON' )
if ( ( nsub .ne. 18447 ) .or. &
( nint(r8vals(1,1285)*100) .ne. 4328 ) .or. ( nint(r8vals(2,1285)*100) .ne. -7910 ) .or. &
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the excess parens are not necessary.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree they're not needed, but IMHO it's better for readability to have those extra parentheses surrounding each logical operator in the expression, and which is why I usually write them that way.

test/intest7.F90 Outdated
iret1 = igetprm ( 'MXNRV' )
errstr_len = 1
iret2 = igetprm ( 'DUMMY' )
if ( ( iret1 .ne. 5 ) .or. ( iret2 .ne. -1 ) .or. &
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check results as soon as you get them. So test iret1 right after linke 74 instead of waiting to call igetprm() again.

It should be generally the case that after every call to the library in a test, you should test every value that can be tested. before calling another library function.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, good suggestion, and will do

test/intest7.F90 Outdated
call ufbrep ( 11, r8val, 0, 1, nr8v2, 'TIDER' )
idx2 = index( errstr(1:errstr_len), 'UFBREP - 3rd ARG. (INPUT) IS .LE. 0' )
if ( ( nr8a .ne. 2 ) .or. ( nr8v .ne. 0 ) .or. ( nr8v2 .ne. 0 ) .or. ( idx1 .eq. 0 ) .or. ( idx2 .eq. 0 ) &
.or. ( nint ( r8arr(1,1) ) .ne. -10000 ) .or. ( nint ( r8arr(1,2) ) .ne. 16 ) ) stop 4
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of these values like r8arr can be checked before later library calls. If they are incorrect, we want to exit immediately, not run additional library code.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, good suggestion, and I'll make a quick pass through all of the intest codes to clean these up. That will probably allow us to reduce the number of declared variables as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to merge this PR and then do variable consolidation in another iteration...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, but I'm going to have to push up another commit anyway to fix the key setting in developer.yml, so I may as well do all of this together ;-)

print *, 'Testing writing OUT_3 using ISETPRM and IGETPRM, using EXITBUFR with multiple allocations,'
print *, 'and using 2-22, 2-36 and 2-37 operators.'

#ifdef KIND_8
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any tests where we have to change the settings for KIND_d?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, because both _d and _4 use 4-byte integers.

The only difference in these two builds is that the former uses 8-byte reals instead of 4-byte reals. But unless we missed something, every real call parameter is already explicitly passed as real*8 anyway in the library specs, so the two builds are now basically equivalent from a library interface perspective.

edwardhartnett
edwardhartnett previously approved these changes Feb 25, 2023
@jbathegit
Copy link
Collaborator Author

BTW, thanks for the explanation of how to force the runner to change the data in the cache! I'll take care of that when I push up the next commit.

I may still have one new intest code to add if I can get my hands on a sample prepfits file, and in which case I can cook up a test for the ufbin3 routine as well. I'll keep you posted.

@jbathegit
Copy link
Collaborator Author

BTW, I'm guessing I'm going to need to update that key setting in all of the .yml files, not just in developer.yml, correct?

At the moment, we have the following in each of the .yml files:

  • developer.yml key: data-1
  • Intel.yml key: data-1
  • Linux.yml key: data-1
  • MacOS.yml key: data-2

So MacOS is already pointing to a different data-2 key - do you have any idea why? And does this mean that I should now update all of them to be key: data-3?

@edwardhartnett
Copy link
Contributor

Just increment all the keys by 2 and that should work. MacOS has a different cache from Linux, IIRC.

@jbathegit jbathegit marked this pull request as ready for review March 2, 2023 19:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cause tests to fail with non-zero return code Tests require documentation, but not doxygen
2 participants