RIM-W interpolation crash due to automatic RandGvecW override

[stevenbos123]

Dear Developers,

When running Yambo with the rim-w flag on a 2D system, the code crashes with the following error:

<03m-28s> P1: [09.01] RIM-W interpolation
<03m-28s> P1: [WARNING] RIM-W works only for 2D semiconductors with slab cutoff
P1: [ERROR] STOP signal received while in[09.01] RIM-W interpolation
P1: [ERROR] G_max 15 for RIM-W is higher than G_max 1 of vX

This occurs when NGsBlkXp is set lower than RandGvecW. In my input, I explicitly set both NGsBlkXp and RandGvecW to 1 RL as a test before running a full GW calculation. However, Yambo internally overrides RandGvecW to 15 RL (the minimum for 2D systems), which leads to the mismatch and the crash.

While I understand the need for a minimum RandGvecW, it is inconvenient that this mismatch causes the entire database to become unusable, requiring a full restart of the GW run. This is especially painful because RIM-W is step 9 in the GW workflow, and a failure there means losing all previous progress. For a minimum test calculation, this is no problem. But when by accident this happens for larger calculations it is painful.

Suggestion:

It would be very helpful if Yambo could issue a warning and exit early.

Alternatively,  a more graceful handling of this mismatch would help users avoid the full recomputation (change NGsBlkXP accordingly).

I tag @rreho, as he knows more on this behaviour.

[sangallidavide]

I just checked in the code. There is not such a thing as "a minimum for 2D systems".
There are just two lines in which RIM_W_ng is modified, and they reads
if(l_rim_w .and. RIM_W_ng == 0) RIM_W_ng = RIM_ng
which do not explain the behaviour you are describing.

In your flow, are you setting anywhere else 15 G vectors?

Also, I suggest to always run flows with the "-J" option, in order to avoid having databases written inside the SAVE folder.
If the next step of the calculation needs a database from a previous step, this can be explicitly controlled via multiple -J options. Example:

yambo -F 01_run -J 01_run -C 01_run
yambo -F 02_run -J "02_run,01_run" -C 02_run

[rreho]

The error originates in QP_interpolated_W.F https://github.com/yambo-code/yambo/blob/16f94b12c79aa4e604fb55898d965099c88c60af/src/qp/QP_interpolate_W.F#L109C1-L128C3

Even if the user explicitly sets the number of G-vectors via G_max_ibz(1:q%nibz) = RIM_W_ng, the code later overrides this by computing G_max = maxval(G_max_ibz) based on a check. This value is determined indirectly via the find_q_nns function, which assigns idx_G, and ultimately updates G_max. Correct me if I am wrong.

This behavior suggests that a minimum number of G-vectors is required for the algorithm to correctly account for neighboring cells.

While this logic makes sense, it would be preferable if users could know in advance the minimum number of G-vectors required. One possible solution is to precompute this number at startup, or provide a warning or hint through tools like yambopy.

Regarding this line if(l_rim_w .and. RIM_W_ng == 0) RIM_W_ng = RIM_ng. I believe he is setting the number of G-vec to 1 and not 0. Could this be a useful hint?

[stevenbos123]

Thank you @rreho for explaining it more clearly. Indeed I think 15 is the minimum number of neighbours in this hexagonal 2D system in the out of plane direction. And yes I had set all the G-vectors to 1
@sangallidavide Thank you for the suggestion, I will start using that feature. I did use the "-J" option, so the databases are not written in the SAVE folder. What I was referring to is this error after restarting with more G-vectors:
P1: [ERROR] Trying to overwrite variable X_RL_vecs in ./gw_dummy//ndb.pp with wrong dimensions