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

NetCDF Topography Integer kind Declaration Issues #489

Open
mandli opened this issue Dec 10, 2020 · 8 comments
Open

NetCDF Topography Integer kind Declaration Issues #489

mandli opened this issue Dec 10, 2020 · 8 comments

Comments

@mandli
Copy link
Member

mandli commented Dec 10, 2020

When attempting to force the default integers in geoclaw to become kind=8 rather than kind=4 (e.g. -fdefault-integer-8) for memory reasons someone ran into the problem that some of the NetCDF code has some explicit declarations that ended up being incompatible with this. We just need to make sure that the explicitly defined integers in topo_module are defined consistently. A quick glance makes this look like it is not entirely trivial as the NetCDF module itself does not seem to define this entirely explicitly.

@mandli
Copy link
Member Author

mandli commented Dec 10, 2020

@bolliger32 I think you were the last one to put some of these in because of some memory issues. Do you remember if you found a specification as to what the NetCDF functions were using by default or were they not explicitly "kinded"?

@bolliger32
Copy link
Contributor

oof I wish I remembered when I put those in. This is the NetCDF function reference I was using at the time. A quick glance makes it look like they are not explicitly kinded?

@mandli
Copy link
Member Author

mandli commented Dec 10, 2020

That's what I was worried about, it does not appear that they define a kind for their integers so that when we force ours to become kind=8 that those in the topo_module no longer match. Was the reason you decided to explicitly type these because of the memory issue you had?

@bolliger32
Copy link
Contributor

well...either that or the fact that I am a fortran beginner and was just trying to be as explicit as possible...do you have an example line in particular? Might trigger my memory

@mandli
Copy link
Member Author

mandli commented Dec 11, 2020

I am not seeing it off hand in my own email but I thought at some point you were talking about a segfaults but I could be thinking of something else, maybe something to do with storm objects. If NetCDF is not expecting an explicit type of integer kind then it's probably best anyway to leave these integers also to be generic to match in any case.

@mandli
Copy link
Member Author

mandli commented Dec 11, 2020

Well it looks like at least for me my compiled version of the NetCDF library has defaulted to integer(kind=4), which should be the defaults. Of course if we force this to not be the case this will not work, which may have been what you were seeing earlier @bolliger32. I will see if I can get the rest of these to behave with -fdefault-integer-8. If someone does compile the NetCDF library with -fdefault-integer-8 then I guess we will have to warn them about this.

@bolliger32
Copy link
Contributor

I was dealing with some segfault issues but I don't think that had to do with explicit "kinding" of integers. I think that was all a separate issue

@mandli
Copy link
Member Author

mandli commented Dec 13, 2020

What my suggestion then to do is to define a variable for all NetCDF integer kinds, say NC_KIND, and set that to default to 4. If someone does want to recompile with kind=8 then they would only have to also change this variable instead of hunt through the code. Also if they decide to compile the NetCDF library with integer(kind=8) then they can ensure that GeoClaw can also do so. This is actually a pretty standard Fortran approach to dealing with kinds of variables. If anyone though has another suggestion though I am open to suggestions.

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

No branches or pull requests

2 participants