That is a known problem with the older BASH version of the profile.d script that initializes modules.
It defines modules as a bash function. When you run a job, it starts a login shell, and the profile.d script then defines the function. The bash shell then executes your script, and that starts another shell. That other shell inherits its environment variables (which prevents the profile.d script from initialising modules once more) but it doesn’t inherit the function.
Note that in more recent versions of bash and environment modules, you no longer have this problem, since the /usr/share/Modules/init/bash will actually export the functions and in subshells re-import them if needed (instead of just thinking ther eis ‘nothing to be done’).
This is on RedHat 8 with the environment-modules-4.5.2-1.el8.x86_64 rpm installed:
[alexis@dragon ~]$ qsub
Job script will be read from standard input. Submit with CTRL+D.
[alexis@dragon ~]$ cat STDIN.o4395
[alexis@dragon ~]$ cat STDIN.e4395
No Modulefiles Currently Loaded.
The workaround is to initialize modules in /etc/bashrc (which will initialize it in all bash shells), or to modify the profile.d script for modules initialisation (to either do the initialisation again regardless of what is found in the environment, or to define the missing function if it does not exist).
Obviously the latter is more parsimonious – only initialise modules if “module --version” returns an error and you’ll only initialise it if needed.
Unfortunately, what you need to do exactly depends on the version of environment-modules and bash you’re using; on, mine you don’t need to do anything. On yours evidently you do. You’ll have to read the /etc/profile.d script and the /usr/share/Modules/init/bash (assuming that is the path, but see the profile.d script to check that) to see exactly what is happening and how to fix it.