Devel lmemcoll

[attacc]

This branch reduces the memory used by collision by about 80%.

Using two strategies: 1) passing from double to single precision for the collisions only 2) removing collisions matrix elements that are zero 3) using Logical instead of Character for COLL%table

tests are running

Claudio

[sangallidavide]

Ciao Claudio, just one comment.

The use of character instead of logical for COLL%table (and the same in the BSE case) was something discussed with Henrique some time ago. A table of characters uses less memory and/or disk space than a table of logicals in fortran/netcdf also allowing for more control. This is why it was chosen. I'll try to find out the discussion.

[attacc]

But not in memory, this for me is the most important point Claudio

Il mar 14 mag 2024, 18:44 Davide Sangalli @.***> ha scritto:

Ciao Claudio, just one comment.

The use of character instead of logical for COLL%table (and the same in the BSE case) was something discussed with Henrique some time ago. A table of characters uses less memory and/or disk space than a table of logicals in fortran/netcdf also allowing for more control. This is why it was chosen. I'll try to find out the discussion.

— Reply to this email directly, view it on GitHub https://github.com/yambo-code/yambo/pull/85#issuecomment-2110682694, or unsubscribe https://github.com/notifications/unsubscribe-auth/AED6PCKHSLKV3PVMGNKA2QLZCI5OVAVCNFSM6AAAAABHWD2TD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQGY4DENRZGQ . You are receiving this because you authored the thread.Message ID: @.***>

[andreamarini]

Hi Claudio. Could you please use the correct name of your branch following the name policy you can find on the wiki page?

In addition. As collisions are also used in the real-time project how does this branch affect the advanced branch?

[attacc]

This change is just for NL, because yambo_nl is in double-precision and uses more memory, it will not affect yambo_rt. For Davide, if you do not like I can move back to character, but honestly store an array of True and False is equivalent so a single integer number, probably one could change the subroutine that write it.

How should I call this branch? tech-collsions is fine?

[sangallidavide]

For Davide, if you do not like I can move back to character, but honestly store an array of True and False is equivalent so a single integer number, probably one could change the subroutine that write it.

Fortran code

 character(1)      :: test_ch                                           
 logical           :: test_l                                            

 write(*,*) "number of bytes for logical ", sizeof(test_l)               
 write(*,*) "number of bytes for charater ",sizeof(test_ch)              

https://gcc.gnu.org/onlinedocs/gfortran/intrinsic-procedures/sizeof.html Output

 number of bytes for logical                     4
 number of bytes for charater                     1

So, moving from character to logical you loose a factor 4 in memory. The reason is that logicals are internally converted in fortran as integers. So, although in principle only 1 bit is required, in practice 4 bytes=32 bits (!) per logical are used. One could use instead

 logical(1)           :: test_l                                            

and it would be equivalent to character memorywise. However you need to pay attention to properly define the logical, and you do not gain anything against the character variable, while possibly loosing features.

This is why, in the end, with Henrique we opted for the character variable.

In the case of the I/O there should be no differences instead https://docs.unidata.ucar.edu/netcdf-c/current/file_format_specifications.html

The external size in bytes of one data value for each possible netCDF type, denoted extsize below, is:
    NC_BYTE 1
    NC_CHAR 1
    NC_SHORT 2
    NC_INT 4
    NC_FLOAT 4
    NC_DOUBLE 8

[attacc]

Thanks Davide, I will restore character. Fortran is a very stupid language :-)

[andreamarini]

Hi Cla. I think that the right name is refact/nl-collisions. It is not a technical advance but rather a refactoring of an existing piece of code.

In addition we need to discuss how to handle these kind of coding. I mean. What kind of commits should enter the master?

We said that the master should be updated few times a year. This means we need to create additional merging points, in my opinion. Let's discuss it on the 22nd.

[attacc]

Ok I will call refact_nl-collisions

I do not like /

claudio

On Wed, 15 May 2024 at 09:31, Andrea Marini @.***> wrote:

Hi Cla. I think that the right name is refact/nl-collisions. It is not a technical advance but rather a refactoring of an existing piece of code.

In addition we need to discuss how to handle these kind of coding. I mean. What kind of commits should enter the master?

We said that the master should be updated few times a year. This means we need to create additional merging points, in my opinion. Let's discuss it on the 22nd.

— Reply to this email directly, view it on GitHub https://github.com/yambo-code/yambo/pull/85#issuecomment-2111783919, or unsubscribe https://github.com/notifications/unsubscribe-auth/AED6PCIRVE4DHH4KGZUBH4DZCMFMPAVCNFSM6AAAAABHWD2TD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJRG44DGOJRHE . You are receiving this because you modified the open/close state.Message ID: @.***>

--

Phone: +33491172806 Mobile[FR]: +33662922897 Mobile[IT]: +393384315437 Fax: +33491418916 Address: CINaM Campus de Luminy 163 Avenue de Luminy, Case 913 13288 Marseille Cedex 9

Skype: claudioattaccalite Editor Fellow for: www.scipost.org web site: www.attaccalite.com