broken fix related to time-split-par (and hence lapH) #195

Closed
wants to merge 13 commits into
from

Conversation

Projects
None yet
4 participants
Member

ggscorzato commented Dec 13, 2012

No description provided.

Owner

kostrzewa commented Dec 14, 2012

Hi Luigi, there is also a compilation error with LapH because the various random functions you are using are not available outside of start.c anymore. Also, the random_jacobi_field function needs to be adjusted to work correctly with the "reproduce_random_numbers" flag (the random_spinor_field_* functions are a good template for this).

Member

ggscorzato commented Dec 14, 2012

hi Bartek, somehow I maneged to compile it two days ago. Now I see the error. I am going to look into it.

Owner

kostrzewa commented Dec 14, 2012

The commit which introduced the LAPH problem is only a few days old. It came as a result of all the random number problems and it is meant to safeguard against these in the future. I've already started the process here:

#193

I think the only way to proceed is to move the "random_jacobi_field" function into start.c

Owner

kostrzewa commented Dec 14, 2012

Although I just noticed that I made a mistake there... I'll fix it now

Owner

kostrzewa commented Dec 14, 2012

Okay, the mistake should be fixed.

@urbach : For unif_vector I had forgotten to multiply by 2*PI... The issue I was seeing was unrelated to this though (it was caused by this #194).

I'm a bit confused by the point of multiplying by 2PI and then dividing by the norm... don't those two actions cancel eachother out? That's also the reason why the code worked just fine without the multiplication by 2PI... The relevant function is currently called "unif_su3_vector" and I think it is not required.

Member

ggscorzato commented Dec 17, 2012

I have moved the random_jacobi_field in start.c for consistency.
I haven't introduced the repro option in random_jacobi_field. I do not think it is needed there. In fact, we do not use LapH to build a Monte Carlo history. It is used only for measurements. If I want to test the parallelization, there are simpler ways.

Contributor

urbach commented Jan 17, 2013

I have submitted a pull request to your branch, @ggscorzato... fixing a (vital) bug...

ggscorzato Merge pull request #1 from urbach/laph
bug in su3vec scalar product fixed, degeneracy in EVs now gone
a21295c
Contributor

urbach commented Jan 26, 2013

here the IO still needs fixing...!

Member

ggscorzato commented Feb 4, 2013

Hi,
I have tested the parallel LapH with the code downloaded on Jan 28 from my master and it works.
Which kind of IO problems do you see?

Contributor

urbach commented Feb 4, 2013

The IO is not standardised. And I'm not sure the LEMON version works at all?

Member

ggscorzato commented Feb 4, 2013

I have used LEMON in my tests. It actually needs LEMON.
What do you mean by standarised?

Contributor

urbach commented Feb 4, 2013

If you run serially, you don't have lime encapsulation, do you? And what about checksums? My student is working on it...

chjost commented Feb 19, 2013

I tried to use the inverter with the laph option enabled, which does not work

Member

ggscorzato commented Feb 19, 2013

The short answer is: when laph is enabled only laph should work...
The reason is that laph is essentially 3D in nature. It reads a 4D gauge configuration, but then it treats it as 3D slices, because this is the idea of LapH. To do this the addressing of the neighbours is changed.
This is actually the main reason why I think that it would be preferable now to branch a version in which we keep only LapH, and remove LapH from the main branch.
It was very useful to start from tmLQCD to implement LapH, but now I believe that keeping them together is more a problem (for both tmLQCD and for LapH) than an advantage.
If none objects I will do it.

Contributor

urbach commented Feb 19, 2013

well, I think it would be really favourable to be able to not store the eigenvectors on disk, but directly apply the inverter. This would require to make laph a module rather than a separate main programme. And it would need its own geometry pointers, I assume...

Member

ggscorzato commented Feb 19, 2013

this has never been an issue in our case, because what fitted in RAM also fitted in the scratch disk, and the writing is fast, with lemon. I agree that on a large system it may become an issue (the speed rather than the space). Is this an issue for you now? Or are you thinking about the future?

Contributor

urbach commented Feb 19, 2013

we are planning to apply all of this also to 48^3x96, if it works at some point. But thats of course in the future, but not so far in the future...

Contributor

urbach commented Nov 17, 2016

I'm closing this for the time being.

urbach closed this Nov 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment