Setting the include path for JIT compiler

[NamjaeChoi]

Hello,

I realized that during the JIT compilation of QFunctions, it always looks for the directory where the source is located to find headers. This incurs huge problems in complicated codes. Is there a way to set the include path for the JIT compilation?

[jeremylt]

You probably want
https://libceed.org/en/latest/api/Ceed/#c.CeedAddJitSourceRoot

I'm not sure I understand what huge problems you forsee. Can you clarify?

[NamjaeChoi]

Thus the user class definition will look like:

CEED_KERNEL(CEEDDiffusionKernel, CEEDDiffusion)
public:
static InputParameters validParams();

CEEDDiffusionKernel(const InputParameters & parameters);
CEED_KERNEL_END(CEEDDiffusionKernel)

[jeremylt]

Hmm, we haven't tried anything like that yet, so I'm curious to see how it works out.

[NamjaeChoi]

Does CeedAddJitSourceRoot receive one directory at a time?

[jeremylt]

Correct. If you want to set multiple new root directories to search from, then you'd need to call this multiple times. Then you can specify the QFunction source path relative to any of the root dirs you've set.

[NamjaeChoi]

Thank you.

[NamjaeChoi]

Hmm does CeedAddJitSourceRoot only affect the relative path to the source? It doesn't seem to work with header include paths.

[lindsayad]

It's not feasible to change every occurrence of "header.h" to <header.h> in MOOSE.

It's not really feasible nor do I think it's very desirable. I think it's fairly common practice to use "header.h" when including files within your own library as opposed to a system or third-party library

[jeremylt]

Ideally, you should not be pulling in a very large number of transitive includes. The more stuff is in all those included files, the higher the likelihood that NVRTCC will refuse to compile.

[jedbrown]

I think libCEED should not try to force a special semantic, but in general, the semantic distinction is with whether the local directory is searched first, not a convention about whether the headers are packaged in "the same library" as the source that includes it. I'd say it's better (and presumably faster in the sense of fewer filesystem operations) to use <header.h> any time you don't deliberately want to search the local directory.

[jeremylt]

I don't know for certain, but I suspect my most recent commit to my branch will support either now? But I still recommend the QFunction source pulls in the absolute smallest number of transitive includes and lines of code that are strictly needed to compile the QFunction. The more that's pulled in, the more risk of unrelated changes breaking a QFunction. (This is why ceed.h was split and ceed/types.h was created: https://github.com/CEED/libCEED/blob/main/include/ceed/types.h ceed/types.h is recommended over ceed.h. in QFunction source)

[NamjaeChoi]

I suspect my most recent commit to my branch will support either now?
Yes, your recent change supports both.

[NamjaeChoi]

Hello,

I guess it would be great to have a feature to provide preprocessor definitions as well. The error we are seeing

/data/choin/moose/libCEED/backends/cuda/ceed-cuda-compile.cpp:125 in CeedCompile_Cuda(): NVRTC_ERROR_COMPILATION
/usr/include/gnu/stubs.h(7): catastrophic error: cannot open source file "gnu/stubs-32.h"
  # include <gnu/stubs-32.h>

is caused by the lack of compiler-provided preprocessor on the system architecture. stubs.h looks like:

#if !defined __x86_64__
# include <gnu/stubs-32.h>
#endif
#if defined __x86_64__ && defined __LP64__
# include <gnu/stubs-64.h>
#endif
#if defined __x86_64__ && defined __ILP32__
# include <gnu/stubs-x32.h>
#endif

I know your response would be not including this header, but that is not easily doable in the current MOOSE.

[jeremylt]

There has to be ways to firewall that though and limit the total number of headers needed in JiT. For Ratel and HONEE, for example, we have headers that contain the bare minimal definitions and includes needed for JiT, and those minimal headers are included in the physics source files and the other headers that are used in the full compilation environment.

My concern is that by pulling every header on the system related to MOOSE into the JiT you'll end up feeding me a never ending stream of issues, and I've got a lot of high priority tasks on my plate right now. I can only work so fast, so I'll bottleneck your work if that's the case.

[jrwrigh]

Misc googling shows that NVRTC should provide the __x86_64__ definitions. CEED_DEBUG=1 might help find the issue; it'll output the raw text passed to NVRTC, but that obviously won't factor in the preprocessing done by NVRTC afterwards.

[NamjaeChoi]

Doesn't have to be fast. I'm just suggesting and I respect your priorities. I think I can somehow workaround for the time being by using function pointers even though hurting performance. @jrwrigh Thanks for the link.

[jeremylt]

#1699

[NamjaeChoi]

Thank you for picking it up quickly!