Discussion: replace 'N_spin' and 'N_sites' with 'N_flavors'?

[fsohn]

Just an idea for a small discussion:
It might be confusing for users, if there is an 'N_spin' as well as an 'N_sites' value, when the code is actually working on 'flavors'. As far as I understood, the only difference between setting e.g. 'N_spin=2, N_sites=3' and 'N_spin=1, N_sites=6' is the automatic setup of the global spin swap update. If the user does not use the order '1up, 1dn, 2up, 2dn, 3up, 3dn', but e.g. '1up, 2up, 3up, 1dn, 2dn, 3dn', this update does not do what it was intended for. So, in my opinion it would be easier to just use a general flavor number 'N_flavors' and let the user specify the 'swap_vector'. What do you think?

[shinaoka]

Thank you for the suggest. I agree.
This interface has turned to be confusing.
In the next version, I will replace N_sites and N_spins with N_flavors
and a new option with which user can specify the ordering of spins.
These will solve this problem.

[dombrno]

Good morning, I must say that I agree that N_spin and N_sites is not the ideal interface. Ideally, the changes you suggest would be very good. This being said, I can imagine it will be very difficult to ensure backwards compatibility with such a change, which could be unsettling for users who have made the effort to adapt their own codes to this convention, as I have done. Let me use this opportunity to thank you for an amazing effort producing this code and offering it open source to the community.

[shinaoka]

Hi, backwards compatibility is important as well.
We may be able to mark N_spin and N_sites as deprecated and introduce new options at the same time.
After a while, it will be safe to remove the old ones.

[egull]

Agreed that it is confusing. Historically this was done when we generalized the single-site code to three orbitals and clusters. At the time it made sense – but not anymore.

[dombrno]

One possibility might also be to move towards the same convention as another impurity solver in the AlpsCore range of codes, e.g. https://github.com/ALPSCore/CT-HYB-SEGMENT . It would have the added benefit that it would avoid errors for people (like me :) ) who have adapted the segment code so that it uses a similar input as this matrix solver - allowing for the study of systems both in the density density approximation, and with more realistic interactions. IIRC, things like N_orbitals are used in the segment code.

[egull]

Indeed – or rewrite both of them that we have a consistent interface that people like you like. I think this is mostly a problem with documentation and error handling... I'll bring it up next time we do changes to the segment code.

[dombrno]

That is my opinion as well. In this respect, the overall architecture of the input parameters of the matrix code is excellent in my opinion - text file, and separate sections for each type of quantity computed/physical parameters/model parameters.

[shinaoka]

Yes, I will also keep it in my mind.

[shinaoka]

By the way, if you're using a GCC compiler, it may be better to upgrade it to the latest version. Optimization was not activated by default...

The next release will include a lot of updates on two-particle GF. There is a plenty of time to think about better interface.

[dombrno]

Oh, these are interesting things to note. I am using intel compiler, but the updates on 2p GF I am quite eager to discover :)

[fsohn]

Thanks for all the responses! I agree that it would be great to have an input file style, that is consistent for both the segment and the matrix solver. Also, keeping the old 'N_spin/N_sites' convention additionally for some time and marking it as deprecated seems to be a good idea.

[shinaoka]

Thank all of you for the suggestions! I will put this to a long-term issue.