Yambo Community Forum

Hi, Daniele
Thank you for your quick reply!
The problem is only happening when I do TDHF. I said I used infinity coulomb cutoff means I used an infinity cylinder coulomb cutoff. And it was working in my BSE calculation.

"Have you produced your database using pwscf, or you used the one provided in the tutorial?"
I have produced my database by PWSCF, only used the same coordinates and other similar parameters from tutorial. But it was working when I did BSE calculation with my database, no similar warnings. But if PWSCF doesn't work, will abinit avoid this problem?

The reason I connect this problem with coulomb cutoff is that if I do the same calculation with Random Integration Method for the 1D system, the calculation can be finished and the results look reasonable, (now I am not confident whether the result is correct or not because the same warning about database and pseudopotential are there too.)
But if I do with coulomb cutoff, the calculation stuck at "Diagonalization solver".
thanks!

yuan ping
University of California, Davis

Dear Yuan,

The problem is only happening when I do TDHF. I said I used infinity coulomb cutoff means I used an infinity cylinder coulomb cutoff. And it was working in my BSE calculation.

OK, I see, if I well understood this is related to TDHF and not to BSE. Now you are still using an infinity cylinder coulomb cutoff.

I have produced my database by PWSCF, only used the same coordinates and other similar parameters from tutorial. But it was working when I did BSE calculation with my database, no similar warnings. But if PWSCF doesn't work, will abinit avoid this problem?

Ok, so the warning about pseudopotentials is normal. Abinit will avoid this warning, but the problem should not at all related to that.
The other warning should not be there.

The reason I connect this problem with coulomb cutoff is that if I do the same calculation with Random Integration Method for the 1D system, the calculation can be finished and the results look reasonable, But if I do with coulomb cutoff, the calculation stuck at "Diagonalization solver".

Ok, I will look at it as soon as I have time, can you please post your input and report files?

Daniele

Dear Yuan,
in order to look at your problem, let me ask you to post your input files and reports:
both the working ones (BSE and TDHF with RIM) and the not working one (TDHF cutoff),
as well as the pwscf input as I can reproduce your situation.

Cheers,

Daniele

Dear Daniele,

Thanks for your patience!
I have attached an example I did with TDHF with this post.
I am still interested in the TDHF calculation with coulomb cutoff by your code if possible.
I want to use the tdhf result by yambo as a reference but I don't know whether the result is correct even when the calculation is finished. (I mean in the situation with all the warnings I told you before.)
If "missing non-local posedopotential" is a problem with PWSCF, will it also affect other calculations such as BSE ? Actually I didn't get such warnings when I did BSE calculations with pwscf.
If abinit is reliable with yambo in any calculation, I could try abinit.
best,

yuan ping
University of California, Davis

Dear Daniele,

I just realized that the previous BSE calculation was done with abinit. In fact I rarely use abinit. The calculation looks fine to me .
Since I have done some calculations with pwscf for TDHF, I hope I can understand whether they are wrong or not.
thanks!
yuan ping
University of California, Davis

Dear Yuan,

I want to use the tdhf result by yambo as a reference but I don't know whether the result is correct even when the calculation is finished. (I mean in the situation with all the warnings I told you before.)

The warning related to the database does not take any effect, don't warry at all, yambo looks there a database that there is not, but you do not ask to read it.
This messaging has been corrected.

If "missing non-local posedopotential" is a problem with PWSCF, will it also affect other calculations such as BSE ? Actually I didn't get such warnings when I did BSE calculations with pwscf.

This is a well known problem that you have when pwscf is used for gs calculations. This problem is discussed in the forum, and you can find it
here. It should anyway affect the intensities of your spectra and not the position.

Anyway, the problems you are experiencing they are not due at all by this fact.

I just realized that the previous BSE calculation was done with abinit. In fact I rarely use abinit. The calculation looks fine to me .

Looking at your input, I see that you used the cutoff for the BSE, but you did not for the calculation of the screening W. This is
rather inconsistent.

Since I have done some calculations with pwscf for TDHF, I hope I can understand whether they are wrong or not.

It is not easy, the files you sent me are quite dirty, in the sense that the TDHF calculations are done on top of previous calculations,
you can recognize it form the report where previous file are read, and there are several warning about inconsistencies of variable.
That's why I asked you to test the calculations by scratch. Moreover from the report it looks that the calculations is finished and not stacked,
the last section of the report is "Game Over and Game Summary". Well there is some confusion there and it is not easy to understand
what's happening. Could you please repeat your tests from scratch and report what's really happening? If you can do this, please try to
change just the variable you are interested in the test. For instance in the TDHF you include 1-5 bands when using cutoff and 1-2 bands
when the RIM in the input (in this way the BSE matrix ha different dimension!, that could bring to memory issues problem),
while the report indicates you are always using 2 bands, so I do suspect the report you sent me does not correspond to the input.
Another issues: in the BSE you use 111 Gvec in the direct term, while in the TDHF you have 23583 (again, very different memory needs).
I continue to suspect that there are some memory issues not at all related with the cutoff or the rim, but at this stage is difficult to say this.
If you can repeat some clean tests, post them and I will try to help you.

Cheers,

Daniele

Dear Daniele,

Sorry for the confusing files I sent you. Yes, the calculations have been restarted when I discovered the jobs crushed or stopped.
I'll redo the calculation from scratch and then send it to you later. But the situations I have told you have happened to me before but I have to reproduce them.
thanks a lot.

yuan ping
University of California, Davis

Hi Daniele,
Thank you for all your patience.
I have attached the new calculation with this email. Previously I told you for calculation with cutoff, it will get stuck in BSE solver stage. In fact, it takes more time to stay in that stage than RIM. Then it will go on but without solving BSE. In the output, it shows:
BSSmod= "" # [BSS] Solvers `h/d/i/t`
does it mean the solver is not used?

BTW, I see you are the author of the paper about Hchain: PRL 101, 133002 (2008)
Could you tell me how many K points and which cell size you use for this paper? I got the information from tutorial (25a.u.cell, 80kpoints). Is this what you use
in the paper? I find actually it's quite hard to converge the cell without coulomb cutoff.

thanks again!
yuan ping
University of California, Davis

Dear Yuan,
believe me, it's very difficult to help you in this situation.
Please have a look at your report files: in the tdhf/cutoff
it doesn't look to correspond to the input you sent me.
It is made on top another BSE calculation having 200 bands in
the kernel and a different number of Gvector in the exchange and direct term.

In the bse calculations too, something went wrong.

Anyway I have reproduced the error, and I will try to have a look on what's happening.
I will let you know as soon as I understand the source of the error.


Daniele

Dear Daniele,
As I told you the calculations have been redone.
For the tdhf/cutoff, I attached the crashed calculation which didn't finish in the time limit. That's why I restart the calculation.
But the input should correspond to the output.
I have met a lot of cases that the gvectors have been changed during the calculation for some reasons. It could because it wants a complete g shell
or there is a bug somewhere.
The one I sent you before is the finished one. But skip BSE kernel calculation.
thanks!
yuan ping
University of California, Davis