Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

strange behavior of LRF #19

Open
JordiVillaFreixa opened this issue Feb 6, 2024 · 11 comments
Open

strange behavior of LRF #19

JordiVillaFreixa opened this issue Feb 6, 2024 · 11 comments

Comments

@JordiVillaFreixa
Copy link

in two different systems, late installations of Q6 (since September 2023 at least) are creating memory problems (segmentation fault). The problem has been tracked with the debug compilation and we have identified that it is the LRF calculation which produces the errors. Before going into more detail, is that an identified issue by the developers?

@acmnpv
Copy link
Contributor

acmnpv commented Feb 6, 2024

Hello, I have been told about something like this as well a few weeks back, but have not been able to dig too much into it due to work and family issues. Can you add the debug trace here so I can compare it to the other one I received?

@ND7996
Copy link

ND7996 commented Feb 7, 2024

Dear Paul ,

I am sending the files with the debug while compiling

outputmakedebug.txt - com - make debug
outputmakealldebug.txt - com - make all debug
outputmakeall.txt - com - make all COMP=gcc

initial error when running relax.

error.txt

@acmnpv
Copy link
Contributor

acmnpv commented Feb 8, 2024

Hello, I had a quick glance at the log file, and can already see that you have an issue with your system charge, as your Q/classical system charge is not an integer value.
This shouldn't cause any crash, but will create issues with the physical representation of the system later.

Can you run your input with the debug build of Q6 as well?

@ND7996
Copy link

ND7996 commented Feb 8, 2024

Thank you for your response , will check the issues with charge but now I only tried compiling with the
command - make debug which shows an error as below
makedebug_error.txt

Then i tried make all debug which is as follows

makealldebug_output.txt

and the output as below with the debug build

relax_001.log

@acmnpv
Copy link
Contributor

acmnpv commented Feb 8, 2024

hello, your latest run is still from the non-debug build.

I need to see if I can try to reproduce the issue with the debug build

@ND7996
Copy link

ND7996 commented Feb 8, 2024

Apologies, here is the file with Debug built

relax_001.log

@acmnpv
Copy link
Contributor

acmnpv commented Feb 9, 2024

thanks! The issue is the same as I have seen before, where an invalid charge group is being used for the calculation (dr = lrf(ic)%cgp_cent - x(i), where as far as I can see the lrf(ic) field points to uninitialized memory)

The thing is that I honestly don't know what changed there that makes this bug appear now after all this time, and I don't currently have the time to run this through a debugger the investigate further.

If I find the time over the weekend I might be able to do some more checks

@JordiVillaFreixa
Copy link
Author

Thanks @acmnpv , in the meanwhile we'll try to check the issue of the charge, which surely does not help having a smooth run. It would be good having a check in Q6 that prevents reaching the segmentation fault problem when issues like this happen. Thanks a lot.

@ND7996
Copy link

ND7996 commented Feb 14, 2024

Hi Paul

we have been looking for the error and found that it is in the execution in linux. We tried with two compilers (gcc and ifort) but the segmentation error still stays when running Qdyn. While in Mac the Qdyn runs well.
i am sending my relax inputs and output error with debug built and using the compiler ifort, with the fep and topology file as well.
mousecysrelax_ifort.zip

@acmnpv
Copy link
Contributor

acmnpv commented Feb 15, 2024

did you use an ARM Mac, or an x86_64 processor one? It would be another datapoint for me to look at.

@JordiVillaFreixa
Copy link
Author

intel x86_64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants