RasOrb vs JobIph

[ramess101]

I have found a temporary fix for Issue #8 that has allowed me to successfully run the all_run_init.sh file. However, the OpenMOLCAS calculations fail with the following error about not being able to find the JobIph file:

This error can be traced back to SHARC_MOLCAS.py line 3588:

I am confused why Sharc is looking for JobIph. In the tutorial we clearly specified RasOrb files instead of JobIph:

Do I need to use JobIph instead?

[ramess101]

I have attached the MOLCAS.out file. It appears to end abruptly with no clear error reported.

MOLCAS.out.txt

[ramess101]

After digging a little further, I believe the MOLCAS.out file terminated properly. The "Error Code: 1' output comes from SHARC_MOLCAS.py line 3811:

Could it be that the error is actually related to the wfoverlap package? Perhaps wfoverlap is not creating the JobIph files that are then required in subsequent steps?

[ramess101]

The code now seems to be running properly, i.e., the "run all_run_init.sh" command completed without any errors, hurray! I made two significant changes to arrive at this point:

1. I rebuilt wfoverlap. I forgot that my first time trying to build wfoverlap was unsuccesful. To avoid getting stuck, I originally just moved on in the tutorial.
2. I changed my scratch directory from my home directory (which has very limited size constraints) to an actual system wide scratch directory.

The first change did not appear to solve the problem alone. In other words, even with wfoverlap built properly I still got the same error. But I can't say definitively that step 1 wasn't necessary, because I had tried step 2 several times before trying step 1 without any luck.

Before closing this issue, I would appreciate any additional insight you could provide as to the real cause of this error and words of caution moving forward.

[maisebastian]

Dear Richard,
here some answers to your questions:

1. Regarding the RasOrb vs JobIph files:
   The SHARC-MOLCAS interface can use both file formats to read in the initial orbital guess. Therefore, inside setup_init.py you get to choose which format you provide the orbital guess in. However, after a successful computation, the interface will always save the JobIph file to the save directory. This is because the RasOrb file contains ONLY the orbitals, but the JobIph file contains the whole wave function. The latter is needed in order to compute the wave function overlaps between two subsequent time steps.
   In your case, you received the error message "JobIph not found" because the MOLCAS job did not finish properly, as is evidenced by the MOLCAS.out.txt file that you have attached. Hence, the main problem here could be that the error message is not too helpful, but it is difficult for the interface to figure out what exactly went wrong.

2. Regarding the error code:
   The error code that can be seen in the png in your first post does not originate from the runOVERLAPS routine, but rather from the runMOLCAS routine. But this error code is simply the error code that MOLCAS reported back. Looking at your MOLCAS.out.txt file, I would guess that there was some problem with the MOLCAS calculation (network problems, full disk, etc), therefore MOLCAS stopped, SHARC received the error code 1. However, since there are some quantum chemistry codes that do not really faithfully return error codes, the interface continues anyways, until it stops when it realizes that the JobIph files are not there.

3. Regarding that the code runs now:
   It sounds very much like your problem was not related to wfoverlap, as wfoverlap.x is only used by the SHARC-MOLCAS interface if you compute Dyson norms, which is not part of the full tutorial. However, it could very well be that the scratch directory has some influence on successfully running MOLCAS. Unfortunately, the error message of MOLCAS ("Aborting...") is very nondescriptive, so it is hard to say what the problem is.

I hope these informations help you a bit further in solving your issues with OpenMOLCAS and SHARC. If your problems still persist, please tell us, and we will figure out a way to investigate the issue further.

Best,
Sebastian

[ramess101]

@maisebastian

Thank you for the very helpful detailed response. Some thoughts:

1. OK, so my initial suspicion was correct that the MOLCAS calculation did not complete properly. This makes more sense now.

2. I had thought overlaps were computed as part of the tutorial. But if that is not the case, I am worried that wfoverlap might still not be installed properly. I ran “make test” and some tests were successful but others were not. Is there another simple way to check if wfoverlap is working? And can you kindly explain when I would actually need wfoverlap?

Thank you again

[maisebastian]

You are right that in the tutorial we indeed compute overlaps. However, the MOLCAS interface is special in this respect, because it employs RASSI to do all normal overlap jobs. Hence, if you run with MOLCAS, you need the wfoverlap program only in order to compute Dyson norms (a quantity related to ionization probabilities, so only important if you include ionic states in your calculations). You do need wfoverlap for overlaps if you use any of the other quantum chemistry interfaces (Molpro, ADF, Gaussian, Orca, Bagel, Turbomole, Columbus).

When you say that some tests were successful and other were not, my first guess would be that you only compiled wfoverlap_ascii.x but not the full version. This is not a big problem, because the only difference is that the latter version is linked against some Molcas-Columbus libraries. This means that with only wfoverlap_ascii.x you cannot compute Dyson norms for MOLCAS and cannot compute overlaps/Dyson norms for COLUMBUS. All other quantum chemistry interfaces (Molpro, ADF, Gaussian, Orca, Bagel, Turbomole, Molcas for overlaps) work fine with wfoverlap_ascii.x. Note that installing the full version of wfoverlap.x requires that you have a working installation of Columbus, including the Molcas-Columbus link that is rather difficult to install.

[ramess101]

@maisebastian

OK, that makes sense. I foresee using MOLCAS in the immediate future but I could potentially switch over to MOLPRO or COLUMBUS, depending on my satisfaction with OpenMOLCAS. So at some point I might need to revisit the wfoverlap installation.

Yes, I should have clarified, I only installed wfoverlap_ascii.x. The two tests that failed were CH2_Dyson (as you explained) and Adenine_fc. But to be clear, Adenine_fc actually did not report a failure, it simply hung there indefinitely. In the end, I commented out the Adenine_fc test so that the "make test" would complete the other tests.

[maisebastian]

The CH2_Dyson and Adenine_fc tests should work, even without compiling wfoverlap.x with Molcas-Columbus support. The important aspect is not from which quantum chemistry program the input comes, but in which format. For Columbus and Molcas, we support that the AO overlap integrals are directly read from the binary integral files (ONEINT or aoints). So if the AO overlaps are in binary format, you need the full, linked version of wfoverlap.x. But if the overlap matrix is provided in ASCII format (as in Adenine_fc in files S_a and S_mix, or in CH2_Dyson in S_ao), then the wfoverlap_ascii.x should also work.

Maybe you are missing a link called wfoverlap.x pointing towards wfoverlap_ascii.x? If you do not compile wfoverlap.x, then one should put this link so that in all cases wfoverlap_ascii.x is called.

You can also relatively easily try the test jobs yourself to see which one failed. Just make a copy of one of the IN_FILES directories (inside wfoverlap/test_jobs). Open the run_test.bash file, and try the jobs interactively, e.g., $SHARC/wfoverlap_ascii.x -f ciov_all.in (example for Adenine_fc). They should finish in a few seconds, printing an overlap matrix at the end. You can also compare the output to the files in REF_FILES.

[ramess101]

@maisebastian

Thank you for the explanation and the direction. I will try running the test jobs manually.

As for the link, I verified that there is a symbolic link pointing wfoverlap.x to wfoverlap_ascii.x, so that should be working properly.

[ramess101]

@maisebastian

I am going to close this issue for now. I will revisit the wfoverlap concerns in a separate issue once I get around to testing it (could be a while since I don't actually need wfoverlap right now).

Thanks again

[MaxParadiz]

Hello @ramess101,

Your error looks like the one I was getting. This is due to the 'WorkDir' and the 'OutputDir' being set to the same directory. You can fix it by chaning your "MOLCAS_OUTPUT" variable.

See: #11