error while populations.py, Installation done wrong?

[jakobcasa]

Dear all

I have run LVC dynamics (first time), and when I ran the $SHARC/populations, the following error occurred. After all the TRAJ_XXXX seemed OK to the program.

Traceback (most recent call last): File "/storage/homefs/jc22p286/applications/sharc/bin/populations.py", line 1348, in main() File "/storage/homefs/jc22p286/applications/sharc/bin/populations.py", line 1336, in main INFOS = do_calc(INFOS) File "/storage/homefs/jc22p286/applications/sharc/bin/populations.py", line 778, in do_calc nsteps = int(INFOS['maxtime'] / dt) + 1 UnboundLocalError: local variable 'dt' referenced before assignment

When I double-checked whether or not there was any data in the output_data folder, I realized that the files in there were there, but nothing useful had been written in there. But when I go into the output.lis file, something is written, even though the time per step was only one second or shorter. Did I do something wrong during the installation of pysharc?

But when I run the test from 11-13, the compile (e.g., error code 0) also they not have the same length(see below), so I suspect that the length of the output in the test cases is also 0. What I found strange, though, is that in the output.lis there are numbers are printed for every step

#########################Full input#########################

pwd /storage/homefs/jc22p286 sharc /storage/homefs/jc22p286/sharc-lvc/sharc/bin joblist ['LVC_overlap', 'LVC_pysharc', 'LVC_pysharc_netcdf'] interfaces {'LVC'} otherenvs set() SCRADIR /storage/homefs/jc22p286/SCR

Do you want to setup the specified calculations? [True]

================================================================================ || Running test jobs... ||

/storage/homefs/jc22p286/sharc-lvc/sharc/bin/../tests/INPUT/LVC_overlap 2024-02-29 17:07:06.869147 2024-02-29 17:07:23.374923 Runtime: 0:00:16.505776 Error Code: 0

/storage/homefs/jc22p286/sharc-lvc/sharc/bin/../tests/INPUT/LVC_pysharc 2024-02-29 17:07:23.378313 2024-02-29 17:07:25.429713 Runtime: 0:00:02.051400 Error Code: 0

/storage/homefs/jc22p286/sharc-lvc/sharc/bin/../tests/INPUT/LVC_pysharc_netcdf 2024-02-29 17:07:25.432682 2024-02-29 17:07:26.088442 Runtime: 0:00:00.655760 Error Code: 0

================================================================================ || Test job analysis ||

------------------------LVC_overlap------------------------- /storage/homefs/jc22p286/RUNNING_TESTS/LVC_overlap/output.dat /storage/homefs/jc22p286/sharc-lvc/sharc/bin/../tests/RESULTS/LVC_overlap/output.dat Output and Reference have different length! ------------------------LVC_pysharc------------------------- /storage/homefs/jc22p286/RUNNING_TESTS/LVC_pysharc/output.dat /storage/homefs/jc22p286/sharc-lvc/sharc/bin/../tests/RESULTS/LVC_pysharc/output.dat Output and Reference have different length! ---------------------LVC_pysharc_netcdf--------------------- /storage/homefs/jc22p286/RUNNING_TESTS/LVC_pysharc_netcdf/output.dat /storage/homefs/jc22p286/sharc-lvc/sharc/bin/../tests/RESULTS/LVC_pysharc_netcdf/output.dat Output and Reference have different length!

|| Summary ||

LVC_overlap Different output length. LVC_pysharc Different output length. LVC_pysharc_netcdf Different output length.

Did I do something wrong when I installed the LVC addition (the Normal sharc workes fine). Also, it is to be noted that I had trouble with the installation until it worked. I was able to install the Pysharc but with a "second folder," meaning that I have one sharc folder where I run sharc (the normal one) and one where I run Pysharc from (for the LVC calculation, I did connect the data with the correct folder). Maybe this could be an issue. I hope this was clear

Thank you for your help. If you need any files, please let me know, and I will send them to you.

Best Jakob

[maisebastian]

Dear Jakob, did you run the LVC trajectories with NetCDF output? If yes, note that you need to run $SHARC/data_extractor_NetCDF.x output.dat instead of the regular data_extractor.x. This is because with NetCDF output, only the header is written to output.dat, but no time step data. The time step data is in output.dat.nc.

If this does not solve your problem, we can more closely look into your findings of the LVC tests.

Best, Sebastian

[jakobcasa]

Dear Sebastian

It worked (Thank you for the help), as you can see, for the gnuplot of one of the TRAJ from the D1. Is the time per step generally between 1 and 0 seconds for molecules with 41 atoms? This looked to me a bit fast, even with the knowledge that the LVC approach is much faster than the standard SHARC approach.

Thank you again for helping me out there. I will let you know if still something strange pops up with the LVC approach.

Best Jakob

[maisebastian]

Dear Jakob, LVC with pysharc can easily be faster than 1sec per time step. This depends on the number of atoms, but even more (quadratically) on the number of states.

However, I have to warn you that the energy plot that you show looks suspicious to me. A stabilization of more than 100 eV and energy gaps of several 100eV indicate a problem that we have observed from time to time in LVC. It is often due to too large lambda parameters for low-frequency modes. This leads to dramatic distortions (very large normal mode displacements) and generally unrealistic results. You should be able to see this if you just visualize the output.xyz file (you have to run data_extractor_NetCDF.x with the -xyz option to get it).

Best, Sebastian

[jakobcasa]

Dear Sebastian

Thank you for the input (especially for the -xyz option). As you suspect, the TRAJ is very unphysical; now my next question is, what is there to do that this does not happen? Is there a keyword for it in order to restrict the lambda parameters?

Thank you, and have a nice weekend.

Best Jakob

[maisebastian]

Dear Jakob, in several cases in the past, it helped to remove the responsible modes and/or states from the LVC.template. This was often done manually by changing lines in the template file. The easiest way is simply to set parameters to zero (if you remove lines, you have to change the number of parameters): 1 1 2 71 1.04e-3 => 1 1 2 71 0. # 1.04e-3 Note that if you delete all lambdas and kappas of a given mode, then that mode is effectively removed, as it remains a harmonic oscillator that does not interact with any other modes or states. In order to remove a diabatic state, you can remove all its kappas and lambdas and add a large shift to its epsilon.

You can also try to obtain the parameters again. If you used TDDFT, it might help to use very large integration grids, very tight convergence, and a truncation threshold for the wavefunction overlaps that is very close to 1 (e.g., 0.9999 or something). If affordable, even turning off RI might help. TDA should be on. All of this is because LVC parametrization relies on numerical differentiation of diabatized energies, which is sensible to numerical noise.

Best wishes and a nice weekend, Sebastian

[jakobcasa]

Dear Sebastian

I am sorry to disturb you again; I don't quite understand how to distinguish the low-frequency modes from the others. Under the keyword "lambda" Is it such that the fourth number is the number of the normal mode, and I have only to look for this number (in your given example, it would be the 71 modes) and set the last value to 0? If not, could you tell me how to distinguish the normal modes? I have attached below a cutout of my LVC.templete, it will be more straightforward to show me.

Best Jakob

[maisebastian]

Hi Jakob, yes, sorry for not being specific enough. You are right in your assumption. For kappas, each line is: multiplicity state mode value for lambdas, it is: multiplicity state_bra state_ket mode value

The frequencies of the modes are given in the V0.txt file (or in the molden file used to create that V0.txt). I would certainly consider modes with frequencies below 100cm-1 as low-frequency modes. But not all low-frequency modes are necessarily reason for the diverging behaviour you saw.

Best, Sebastian

[jakobcasa]

Dear Sebastian

I did change the Kappa values and the lambda values for all the modes under 100cm-1 (mode 9 -15) as well as mode 16 -18 with a bash script so that I do not miss anything (sed -i "s/ $i 1./ $i 0 # 1./g" LVC.template where '$i' runs over the modes and i have the same sed command for all other numbers and all negative values), but it still has the same behavior.

Do I need to set up the traj new after I change the LVC.template? (I don't think so since it is a path that stays the same)

What else can I do?

It may be easiest if I send you the my modified LVC.template. But I can not attach this here.

Thank you for looking into this once more

Best Jakob

[maisebastian]

Hi Jakob, no, for testing purposes, replacing the template file and rerunning is enough. Later, with a stable template, you should start at the setup_init.py step again.

I am sorry to hear that the problem still persists. Here some things you can try:

• You can try to identify which normal mode gives you a problem. If you write me an email, I can send you a small python script that can convert output.xyz into the normal modes so that you can plot.
• What about modes 7 and 8? Should they not also be below 100cm-1?
• You could try to reparametrize with very tight convergence criteria everywhere (SCF, opt, integration grids, threshold for wave function overlap, ...), as I wrote above. Additionally, you can try to make the displacement larger to get less noisy results.
• I am not 100% sure I understand your sed command. It looks to me like it only sets to zero those parameters that start with a 1.

Best, Sebastian

[jakobcasa]

Dear Sebastian,

Thank you for the fast reply.

1) I will write you an email, sure thing and thank you for the python script. 2) Mode 7 (-10.96 cm-1) and 8 (-5.57 cm-1) are imaginary (and as far as I have seen, the imaginary frequancies are neglected anyways, which does make sence to me.) 3) the sed command runs over all the "1." and I have the same command for the "2." etc. (1. till 9.) in the bash script. sorry for the confusion

Best Jakob

[jakobcasa]

Dear Sebastian

Thank you again for the Python script, but unfortunately, it gives the following error:

Traceback (most recent call last): File "/storage/homefs/jc22p286/m4/sharc/DSPL_RESULTS/trj/Doublet_1/TRAJ_00013/convert_to_NM.py", line 200, in main() File "/storage/homefs/jc22p286/m4/sharc/DSPL_RESULTS/trj/Doublet_1/TRAJ_00013/convert_to_NM.py", line 178, in main MRV[i] = sum(MR[j] SH2LVC['V'][j][i] for j in r3N) File "/storage/homefs/jc22p286/m4/sharc/DSPL_RESULTS/trj/Doublet_1/TRAJ_00013/convert_to_NM.py", line 178, in MRV[i] = sum(MR[j] SH2LVC['V'][j][i] for j in r3N) TypeError: 'map' object is not subscriptable

Which I don't know how to solve. But I have noticed something in general, which I may have done wrong on a side with all the other stuff. I did change the LVC somewhere in the folder(I guess the original LVC.templet), but instead, I should have changed the LVC.templet file in the folder TRAJ_XXXXX/QM.

In the meantime, I have one more question. To see an effect on the output.xyz, do I need to delete the only output.xyz, or is there something else I should delete before every rerun. until then I will comment out more and more modes and check every time until it works fine.

Thank you for the support until now.

Best Jakob

[maisebastian]

Dear Jakob, the script works as intended for me, without giving an error. Do you run the script with Python 2 (sorry, this is a slightly old script that i sent you)? If you converted it to Python 3, note that the map() function in line 130 works differently in Python 3 (see https://stackoverflow.com/questions/6800481/python-map-object-is-not-subscriptable). You might be able to fix the error if you write list(map(..)) in line 130.

About your other question: If you do not perform a restart (restart keyword in input file), then all output. and restart. are overwritten, you should not need to delete anything before a rerun. After the rerun, also run the data_extractor_NetCDF again, and all files should be corresponding to the new run.

Best, Sebastian

[jakobcasa]

Hey Sebastian,

I tried different things now. First, on the original structure, I commented out the low-frequency modes. Which did not help; then I analyzed it with the help of your Python script, and I did comment out the value of displacement^2 (to catch the negative displacements), where I tried to go down to a value up to a square of displacemet^2 equal to four. with this threshold, I scanned every mode of the molecule and commented out the ones that have, at any time, a higher displacement^2 than four, which did not help either (which was almost every second mode, which I found to be very unphysical). So, I tried to optimize with Orca using the Verythigh option and did not use the RIJCOSX. With this, I produced the LVC.templete one more, and I noticed something odd: comparing the old LVC.templete(lvc_old) and the new LVC.templete (lvc_new), the number of the Kappa and lambda values are different. Namely, the lvc_new has more in the lambda and the kappa values than the lvc_old. I am curious to know whether this is intended. I have run the LVC dynamics again, which has indeed led to better results! But only partially good. When I look at the output.xyz, I can see that a structure which is planar(0 degrees) in the ground state has a max value of 69 degrees, But it is every time recovering from such high values to more physical ones. I don't know if it is helping to reduce this high unphysical value when I repeat the procedure or is this or does this may have the opposite effect. Or I there a way to optimize the optimization job more regarding the output of the LVC?

Thank you for the help Best Jakob

[maisebastian]

Hi Jakob, it might help somewhat to do the opt+freq calculation with stronger convergence criteria. This will get rid of the imaginary modes and might clean up some of the other low-lying modes. However, I think the problem that you have seen (very large displacements lead to large couplings which lead to even larger displacements ...) is mostly related to the lambdas. The kappas are usually fine, because they can be obtained from analytical gradients (if you have used that option).

About your new LVC template file, I am not able to say whether it is expected that there are more parameters with harsher convergence criteria than with loose ones. So far, we have mostly assumed that loose convergence settings lead to more noise, which leads to more random lambdas, which leads to the appearance of larger lambdas.

What is the issue with the new trajectories? Do they still show the same kind of behaviour, just less strongly? Or is something else wrong? Unfortunately, I cannot fully follow your statement about the output.xyz.

Best regards, Sebastian

[jakobcasa]

Hey Sebastian Thank you for the answer. Until now, I did the opt and freq calculations separately because the freq needs to be done in Orca 4.xx. But I'm using Orca 5.xx for the optimization (maybe this could also have an influence); I will try to do the freq in Orca 5 to compare. Or is there an ORCA_freq.py that works with the Orca 5 version? I was not able to use Orca 5, with the ORCA_freq.py? Also, I'm already using VERYTIGHTOPT(and VERYTIGHTSCF), but I could try (even though it is very expensive) to EXTREMESCF. About the output.xyz file, the problem is still there but less pronounced, yes. I will let you know if something interesting is turning up with the Freq calculation!

Thank you for looking into this once more. Best Jakob

[jakobcasa]

Hey Sebastian

The freq calculation in Orca 5 shows no imaginary frequency(and the one in Orca 4 does; two modes are imaginary). Is there an ORCA_freq.py that is able to work with the Orca 5 output file? Otherwise, I would do the optimization and freq calculation in Orca 4 (in one job)!

Best Jakob

[rafaelpap]

Could you share the frequency job run with Orca 5? I have tried ORCA_freq.py with a couple of my own outputs, and it seems to work.

[maisebastian]

I second Rafael's question. ORCA_freq.py from the most recent release or from the main branch should work with ORCA 5. If you have problems, I would appreciate to see your log file.

Best, Sebastian

[maisebastian]

And I just saw your question about the precision of the opt+freq. I would recommend doing both in ORCA 5, using verytightSCF/verytightopt. But note that DFT-based opt/freq jobs are actually most sensitive to the integration grid. If you do not already do it, I strongly recommend you use defgrid3.

We by now also have some evidence that the parametrization of the kappa and (especially) lambda parameters using numerical differentiation can benefit from an increase of the displacement (to values larger than the current default of 0.05). If you continue to experience problems with your LVC model, you recommend that you reparametrize using larger displacements.

[jakobcasa]

Dear all, I was able to "fix" the issue with the ORCA_freq.py. What I did, which was my ORCA_freq.py, was I (lowercase L) printed out the Orca 4.out, there I (lowercase L) was able to see that the quantity that was of interest is the value of T^2 (T**2), with this information, I checked the values printed out in the Orac 5 output, and adjusted the l (e.g. changing l[2] to l[4]). After that did not work, I looked at the text after the table. I noticed that it was different. In the ORCA4, it was something along: "The first frequency considered to be a vibration is 8 The total number of vibrations considered is 115".

In Orca 5, on the other hand, there was some additional text there: "* The epsilon (eps) is given for a Dirac delta lineshape. ** The dipole moment derivative (T) already includes vibrational overlap.

The first frequency considered to be a vibration is 6 The total number of vibrations considered is 117"

and I did change the order in the output file. It results in: "The first frequency considered to be a vibration is 6 The total number of vibrations considered is 117

• The epsilon (eps) is given for a Dirac delta lineshape. ** The dipole moment derivative (T) already includes vibrational overlap."

And it worked. I assume now that the code is somehow confused with the * /** character or it is told to read up till the line"the first freq...." and since the other two lines are in between it got confused. I hope this explanation was clear, if not let me know, and I can try to explain it better. Now I will run through the LVC-sharc code to see whether this does solve the my problem with the unphysical structures. I will let you know as soon as possible.

Best Jakob

[jakobcasa]

Hey Sebastian,

Sorry to disturb you again. I fixed the ORCAversion error by downloading the newest version of ORCA_freq.py. I'm very sorry about this. But the "setting to zero" does not work(see pictures below); the first mode I tried to set to 0 is the mode with the indicated point at X=769.5, Y=265.6. I did check which mode it is by taking the max of the displacement^2 and giving me this value (plotted is only the displacement), which is for the indicated mode a bit higher than 70'000 ( 7.0544e+04). The mode with such a big displacement is the 11th mode, so I went to the LVC.templete of the respective TRAJ and set all the values of the 11th mode to zero. I did re-run the TRAJ again; then I reran the script, which you sent me once more, and I would have expected that the respective mode had vanished entirely or at least very much dropped in displacement. But it stayed the same. The same happened when I set the mode with the second-highest displacement to zero (mode 8). Maybe I misunderstood something, so I will try to describe how I got the attached figures a bit in detail: I did plot every mode concerning the time that has a higher displacment^2 of 9 (e.g., a displacement of 3), and from there, I took the modes with the highest displacement^2 value (X=769.5, Y=265.6) and tried to set to zero. I took the displacement^2 since the displacement can also be negative and do not exclude the negative displacements. Also, here is one line I have changed (as an example):

2 8 20 11 -6.96016e-05 To: 2 8 20 11 0. # -6.96016e-05

Else I do not know what I could have misunderstood.

I hope my meaning was clear; if not, let me know, and I will try to explain more clearly.

Best Jakob

[maisebastian]

Dear Jakob, you are right, if you remove the LVC parameters for mode 11 from LVC.template, then this does not mean that there will be no motion in that mode. However, by setting the kappa/lambda parameters to zero, that mode will have no effect no the relative energies and nonadiabatic couplings in your system. Usually, this is sufficient to remove the influence of the mode. There can still be smaller effects. On one hand, there can be initial momentum in that mode (from the Wigner distribution), which you should see as constant oscillations in that mode. If this happens, then your geometries will not look good, but your electronic dynamics (what one is often interested in LVC dynamics) will still be ok. On the other hand, if you use rescaling of the full velocity vector after a hop, then the surface hopping algorithm will use/put kinetic energy out of/into the mode when hopping. This can also affect the electronic dynamics, depending on the system.

Hence, if you want to get entirely rid of the mode, then you will need to start earlier in the workflow. If you set the mode's frequency (and possibly normal mode vector) to zero in the Molden file before running wigner.py (for initconds and for V0.txt), then the mode should be entirely disregarded, just like the rotational and translation DOFs.

I also just checked the code for parsing the template file in SHARC 3.0. It appears that it does not allow using # for comments in the template file. So your lines

2 8 20 11 -6.96016e-05
To:
2 8 20 11 0. # -6.96016e-05

are actually parsed in the same way (it looks for the 1st-4th and last value on each line, skipping any intermediate ones). Apologies if I explained that in a different way earlier.

So, overall, you should first try to actually remove the lambda values from the template file for real (you can make a backup first). If that does not work, you can still set the mode completely to zero.

Best, Sebastian

[jakobcasa]

Dear Sebastian

Thank you for checking! If I do understand you correctly, I should change the line: 2 8 20 11 -6.96016e-05 to 2 8 20 11 0. And NOT to: 2 8 20 11 0. # -6.96016e-05

And as the second approch, I should delete the line entirely and do that for all of mode 11.

Best Jakob

[maisebastian]

Hi Jakob, to set a lambda to zero, you can either write 2 8 20 11 0. or delete that line (but then you need to change the number of lambda parameters a bit up in the file).

The second approach would be to go all the way back to the freq.molden file, and set the frequency of mode 11 to zero. Then run wigner.py -l to get V0.txt. Then rerun create_LVCparam.py and then check what happened to the parameters of mode 11. You might need to set them to zero again.

Best, Sebastian

[jakobcasa]

Dear Sebastian

I was able to to remove the mode from the pictures when I removed the LVC parameter completely. Thank you. Now I have two questions left: 1) when I did the displacement calculation in some folder the error:

File "/storage/homefs/jc22p286/applications/sharc/bin/SHARC_ORCA.py", line 5278, in main() File "/storage/homefs/jc22p286/applications/sharc/bin/SHARC_ORCA.py", line 5245, in main errorcodes = run_wfoverlap(QMin, errorcodes) File "/storage/homefs/jc22p286/applications/sharc/bin/SHARC_ORCA.py", line 4264, in run_wfoverlap get_Double_AOovl_gbw(QMin) File "/storage/homefs/jc22p286/applications/sharc/bin/SHARC_ORCA.py", line 4377, in get_Double_AOovl_gbw NAO, Smat = get_smat_from_gbw(filename1, filename2) File "/storage/homefs/jc22p286/applications/sharc/bin/SHARC_ORCA.py", line 3945, in get_smat_from_gbw ao_ovl[x][y] = float(out[yoffset].split()[xoffset]) IndexError: list index out of range

What was strange it that the actual calculation did finish correctly, and until now, I was able to solve this by opening up a separate folder and redoing the complete DSPL calculations, but unfortunately, this somehow is not a "global" solution for this issue since I did now a completely new batch and did everything from scratch. It still did appear. If I repeat the calculation, the same issue, happens also a second time. Also, the number of CPUs is not solving this issue.

2) why is the ORCA_freq.py neglecting modes below 10 cm-1?

Thank you for clarifying the point of not using the '#' in the LVC.template

Best Jakob

[maisebastian]

Hi Jakob, the error message sounds like the SHARC-ORCA interface has some trouble parsing the AO overlap matrix from the output that orca_fragovl produces. I guess this might be due to some formatting issues, but I would need to test this for myself to confirm. Could you send me the corresponding DSPL folder (plus DSPL_000) with all input files (and all gbw files if this is a large calculation)?

About question 2., this is not true. ORCA_freq.py will read out all frequencies from orca.log and write them into the Molden file. However, wigner.py will neglect modes below 10cm-1, because these modes are typically very anharmonic and wigner.py assumes harmonic modes. You can change the threshold from 10cm-1 to anything else with the -L flag.

Best, Sebastian

[maisebastian]

Hi Jakob, I finished downloading the files. Note that currently, the link and password is publicly accessible, so you might want to edit your reply. I also did not know that replying via email to Github simply puts it as a reply into the issue thread...

I will come back to you once I know something

[jakobcasa]

This I have realized; thank you, I deleted the howl answer; But thank you for letting me know :) And also for checking

[maisebastian]

Can you check the commit in the main branch for SHARC_ORCA.py? It should fix the index error that you are getting. For some reason, the gbw.old file does not contain orbitals, which threw off the reading of the overlap matrix. Let's see whether the missing orbitals cause other errors, but there is a good chance that it works.

[jakobcasa]

So I think I don't quite understand; I do not find "commit" in the ORCA_freq.py. Which line should I change?

[maisebastian]

You can simply download https://github.com/sharc-md/sharc/blob/main/bin/SHARC_ORCA.py and replace with it the one in your SHARC 3.0 installation. If you are interested in the changes I made, you can find the commit here: https://github.com/sharc-md/sharc/commit/f8bd43e29147d18398b0a4b93d49cbeac98336ab

[jakobcasa]

Dear Sebastian, dear all

It worked finally.

thank you for "remove" this Error, I have only in some cases now the error: Checking for AutoStart: The File: ORCA.gbw exists Trying to determine its content: ... Fine, the file contains calculation information ... Fine, the calculation information was read ... Fine, the file contains a basis set [file orca_tools/Tool-GTO-Bases/basissets.cpp, line 743]: TBasisList: Unable to read number of basis sets!

But this is within the ORCA, and one can fix it by only rerunning the respective displacement; I think this can be closed. Thank you for the many attempts to help me out with the LVC, especially with double-checking the '#' issue. If I have another question, I will just open another issue.

Thank you

Best Jakob

[maisebastian]

Dear Jakob, thanks! Great that it works now. Happy SHARC-ing!

About the ORCA error, I do not know, I have not experienced that one yet. Seems there is also nothing on the ORCA forum... Seems that in some cases the gbw file is corrupted for some of the displacement (and when you run it again, it copies the file again from DSPL_000, which is not corrupted). Could be some file system issue...

Best, Sebastian

[jakobcasa]

Dear Sebastian,

Should I send some files as soon as I experience this error once again?

best Jakob

[maisebastian]

Hi Jakob, I expect that this issue is not related to SHARC, so I will likely not be helpful. If you have something reproducible that is not clearly an ORCA issue, then we can see further whether it's a SHARC issue.

Best, Sebastian

[jakobcasa]

sure :)

Best Jakob