Add compass tags to albany and trilinos-for-albany packages

[xylar]

closes #19

[xylar]

@ikalash, this is ready for you to review when you have time.

[xylar]

This was the only way I found that I could successfully get a URL for compass-* tags that isn't on the usual Trilinos repo. Modifying url_from_version didn't do it, perhaps because it didn't recognize a git tag as a version. Not sure...

[bartgol]

It seems to me that this is a bit involved maybe? Wouldn't it be easier to always use E3SM-Project/trilinos? If lack of sync with upstream is a concern, we could run the sync action more often than once per day (say, every few hours).

[xylar]

@bartgol, it seems like this spack fork is now the one referred to in the Albany documentation and used by Albany testing. It therefore seems strange to have it point to a fork for all work (even if there is a certain consistency between using the E3SM-Project spack for and the E3SM-Project Albany fork). To me, it makes no difference but it seems likely that @ikalash will prefer to keep albany/package.py pointing to the main repo, not the E3SM-Project fork.

[ikalash]

@bartgol, it seems like this spack fork is now the one referred to in the Albany documentation and used by Albany testing. It therefore seems strange to have it point to a fork for all work (even if there is a certain consistency between using the E3SM-Project spack for and the E3SM-Project Albany fork). To me, it makes no difference but it seems likely that @ikalash will prefer to keep albany/package.py pointing to the main repo, not the E3SM-Project fork.

I am getting confused again. I don't think there's an E3SM-Project Albany fork. Are you suggesting to create one? How often will the E3SM-Project Trilinos be sync'ed with the main Trilinos develop branch? If it's daily, I don't see a reason to create a separate Albany fork in E3SM-Project.

[ikalash]

Also, I'd like to test this PR. Are the relevant ways to test this:

• Test by running in my usual way to build albany@develop
• Test by trying to build albany@compass-2023-08-03?

I don't actually do anything with compass in my spack build (or ever). Would I need to build compass first? Or spack takes care of that under the hood?

[bartgol]

I was referring to the trilinos repo. Right now, we set

git = "https://github.com/trilinos/Trilinos.git"

and for version compass-2023-08-03 we provide a special url from the E3SM-Project/trilinos fork. I was wondering if we may as well set

git = "https://github.com/E3SM-Project/trilinos.git"

since we now automatically sync the fork with the upstream every night...

[xylar]

Oops! Sorry for causing more confusion. Yes, we're talking about the repo that trilinos-for-albany points to (not Albany itself). Sorry about that!

Also, I'd like to test this PR. Are the relevant ways to test this:

Test by running in my usual way to build albany@develop

Yes, that's all you should do.

Test by trying to build albany@compass-2023-08-03?
I don't actually do anything with compass in my spack build (or ever). Would I need to build compass first? Or spack takes care of that under the hood?

That is the tag of Albany that Compass will use. You don't need to test that. I'm already doing that on various machines myself as part of this Compass PR:
MPAS-Dev/compass#704

[ikalash]

@xylar : thanks for the clarification. I can test this today. Could you please merge the E3SM-Project spack again into your fork first before I test? I pushed another minor change. This should be the last one.

[xylar]

Sure, I'll rebase.

[xylar]

Done.

[ikalash]

I tested this and things look good. You can go ahead and merge in if you'd like. Sorry about the delay. Note that I did not test things with the compass side of things.

I updated the spack build instructions to mention the @develop part, but we should probably update the instructions to explain the other use case, with the tags. Perhaps you could do this @xylar with help from @bartgol ?

[xylar]

I updated the spack build instructions to mention the @develop part, but we should probably update the instructions to explain the other use case, with the tags. Perhaps you could do this @xylar with help from @bartgol ?

I don't think the compass tags are something we necessarily want to document in the same way as the @develop usage. The compass tags are for usage when we deploy new shared Spack environment in Compass itself, so folks only need to know about the tags when they need to be updated internally in Compass' deployment scripts. Since that's a very specialized thing that currently only I do, I think it's okay if it doesn't get special documentation.