Coder Social home page Coder Social logo

implementation of QM electric field about molgw HOT 10 CLOSED

molgw avatar molgw commented on September 26, 2024
implementation of QM electric field

from molgw.

Comments (10)

bruneval avatar bruneval commented on September 26, 2024

Dear Parisa,

I've been offline for a week. Sorry for the delay.

First, congratulations for your implementation of the transition density.
If you think your piece of code could be used in general, it would be great if you share it.
You could upload your branch or your fork on github and ask for a "pull request".
What do you think?

Second, about adding classical charges.
If I understand correctly, MOLGW is already capable of doing what you want without any hack of the source code.

Correct me if I'm wrong, but I understand you want to place a list of point charges in specific locations.

Please check out the test file tests/inputs/ne_fraccharge.in.

The following line in the atom list adds a point charge without basis function:

-0.001   0.000      2.0  2.0   none none

Is it what you need?

Best,

Fabien

from molgw.

Parisa-1 avatar Parisa-1 commented on September 26, 2024

Dear Fabian

Many thanks for your respond.

-I will be glad to share my branch and think it is usable in general without any specific problem. I will do it ASAP.

-About my question, I think your answer is partially what I need but maybe have to make some adjustment first.
As far as I understood from source code and test file, in the code 'xatom' is consist of QM atoms that call 'natom' and charges save by name 'nghost'. Therefore when code calculates for example Nucleus-electron energy, do cycle goes over both atom sets (QM atom and point charges) and prints Nucleus-Nucleus energy in output file which includes interaction between all nucleus in the system plus interaction between nucleus of the system with point charges.
Please correct me if I understood this part incorrectly.

But what I need is to save the interaction between point charges and the system in different name (e. g E_ED) and not as a part of Nucleus-Nucleus energy or Kinetic Energy. Because in that case I'm able to call this specific energy (E_ED) later on separately. Do you have any suggestion in this regard or I understood the code incorrectly?

Once again thanks for your time :).

Best,
Parisa

from molgw.

bruneval avatar bruneval commented on September 26, 2024

Hi Parisa,

I think you have a point.

But first, let me clarify your statement.
The list xatom with size natom contains all the point charges that generate a Coulomb potential.

The ghost are quite the opposite. These are basis centers that correspond to no Coulomb potential.
The list xbasis contains all the basis centers.

As a conclusion, adding atoms in the list with no basis function, using the syntax

1.0    0. 0. 0.    'none' 'none'

will include them in the xatom list but not in the xbasis list.

Then you're perfectly correct when stating that MOLGW Nucleus-nucleus energy contains all the Coulomb interaction from the list xatom.

So would it suit you if MOLGW would split the nucleus-nucleus energy into two sub-totals:
the "true" physical nuclei and the "fake" ones?

I think this is the only energy type that needs to be split. You mention the kinetic energy in your message, but I do not see why.
Correct me if I'm wrong, of course.

Best

Fabien

from molgw.

Parisa-1 avatar Parisa-1 commented on September 26, 2024

Dear Fabian

First many thanks for your quick response and sorry I back to you a little late as I was on vacation.
I added my pull request for TD calculations today. I'm using it for a while now and the results are correct but sorry if I did not write it in a separate subroutine, therefore, it is a little bit messy.

Okay, now I understood the definition of ghost atoms and thanks for clarifying the process in the code.
About your questions:

  • Sorry I incorrectly mentioned kinetic energy, what I meant was nucleus-electron interaction in that sentence and not kinetic energy.

  • And yes, what suits me is to MOLGW split the energy into two sub-total 'true'(QM atoms) and 'fake'(charges). But I think based on the formalism this splitting not only should be applied to nucleus-nucleus energy but to nucleus-electron interaction as well (subroutine 'setup_nucleus'). It means code can save nucleus-charge and electron-charge coupling energy and add up them in one sub-total (fake).

Will appreciate it if you can correct me about the above statement.

Once again thanks for your help,
Best,
Parisa

from molgw.

bruneval avatar bruneval commented on September 26, 2024

Dear Parisa,
I have merged your contribution after some cleaning.
Can you give me your full name and institution for proper credit?
Thanks.

Fabien

from molgw.

Parisa-1 avatar Parisa-1 commented on September 26, 2024

Dear Fabian

Many thanks for your effort.
My full name is 'Zohreh (Parisa) Hashemi' and for the institution, you can mention 'Institute of Physics, University of Bayreuth, Bayreuth 95440, Germany'.

Best,
Parisa

from molgw.

bruneval avatar bruneval commented on September 26, 2024

So you're working with Linn!
Greet her from me.

Fabien

from molgw.

Parisa-1 avatar Parisa-1 commented on September 26, 2024

Yes, I do. I definitely will do that :).

Parisa

from molgw.

bruneval avatar bruneval commented on September 26, 2024

Concerning your question about splitting the electron-nucleus potential into two parts, I think I disagree.

The extra "fake" charges create an "external" electric field which will polarize the molecule.
I understand that you want to remove the "fake charge"-"fake charge" interaction energy which can be considered as external to our system.

However, in my opinion, we should keep the "fake charge" - "true nuclei" and "fake charge" - "true electrons" interactions in the final summation of the energy.
What do you think?

Fabien

from molgw.

Parisa-1 avatar Parisa-1 commented on September 26, 2024

Dear Fabian

Once again, many thanks for answering my questions.

  • I think there is a misunderstanding here. I agree with your last comment that "fake charge" - "true nuclei" and "fake charge" - "true electrons" interactions should be included in the final summation of energy.
    What I meant before simply was that, to not forget "fake charge" - "true electrons" interactions as before we only talked about "fake charge" - "true nuclei" energy in our emails.

  • So to clarify my intention:
    In the current version of the code, at the end of each DFT cycle code prints out:
    Total Energy = Nucleus-Nucleus + Nucleus Energy + Kinetic Energy + Hartree Energy, ...
    As I understood from our discussion, currently "fake charge" - "true nuclei" energies are included in Nucleus-Nucleus energy, and "fake charge" - "true electrons" interactions are included in Nucleus Energy.

What I want is to save the enrgies in this order:
Nucleus-Nucleus = only "true nuclei" - "true nuclei" interactions
Nucleus Energy = only "true nuclei" - "true electrons" interactions
Fake charge Enrgy = "fake charge" - "true nuclei" + "fake charge" - "true electrons" interactions
Total Energy = Nucleus-Nucleus + Nucleus Energy + Fake charge Enrgy + Hartree Energy + ....

from splitting I meant creating this new "Fake charge energy" sub-energy which later will add up to the final summation of the energy.

What is your opinion in this regard?
Sorry in advance if I still missing a point here and will be glad if you can let me know.

Best,
Parisa

from molgw.

Related Issues (13)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.