RFdiffusion-1.1.0-foss-2022a-CUDA-11.7.0.eb with models and missing dependencies

[ThomasHoffmann77]

(created using eb --new-pr)

• requires {bio}[system/system] RFdiffusion-models v1.1.0, RFdiffusion-schedules v1.1.0 #20019

[lexming]

Test report by @lexming
FAILED
Build succeeded for 6 out of 10 (9 easyconfigs in total)
node200.hydra.os - Linux CentOS Linux 7.9.2009, x86_64, Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (broadwell), Python 3.6.8
See https://gist.github.com/lexming/92ef10c7ef1ab4a78e49ae586dd4cada for a full test report.

[ThomasHoffmann77]

Test report by @lexming FAILED Build succeeded for 6 out of 10 (9 easyconfigs in total) node200.hydra.os - Linux CentOS Linux 7.9.2009, x86_64, Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (broadwell), Python 3.6.8 See https://gist.github.com/lexming/92ef10c7ef1ab4a78e49ae586dd4cada for a full test report.
@lexming I updated the checksums for the DGL easyconfigs.

[smoors]

checksums for git checkouts are not stable, so should be removed

[ThomasHoffmann77]

@smoors I was not aware of the unstable checksums. Is this the case for any commit or only for recursive checkouts?

[smoors]

it's the case whenever you are not downloading a tarball directly, but creating the tarball yourself, so any git clone

[smoors]

what's the difference between the components and _get_schedules/_get_models?
i would prefer to use the best method and remove the other one to keep things clean

[ThomasHoffmann77]

@smoors Using components would archive the models and would allow to reinstall RFdiffusion even if the models were not available for download any more. I'd prefer this option since RFdiffusion is not usable without the models.
However, I understand @lexming's concerns about to store the models data (3.9GB) at least twice, in the module directory and the sources directory.
Therefore I kept the components approach commented out.

[ThomasHoffmann77]

Which solution do you prefer and which should I delete?

[smoors]

hm, i agree with you that having to re-download on reinstall is suboptimal, but i also agree with @lexming that storing the models twice is suboptimal.

a possible solution is to create a custom easyblock that checks the installdir and does not delete/re-download the models if they are already present and if their checksums are correct.
to make this configurable, we could define an extra parameter in the easyblock, e.g. keep_models_if_installed.
this is similar to easyblock Tarball, which allows merging an installation into an existing installation instead of wiping it first.

what do you think?

[ThomasHoffmann77]

For long term it is probably better to place the data into a separate module RFdiffusion_data, which can be reused for minor updates of RFdiffusion, if the data does not change.
It might be good to have a generic easyblock for such data modules, because we can expect more of them with all the upcoming AI packages. (see also #19157 Model-Angelo_data, #19240 relion-classranker_data + relion-blush_data).
There was also a brief discussion at https://github.com/easybuilders/easybuild/wiki/Conference-call-notes-20230719

[smoors]

that's indeed a better solution long-term.
i'll try to give a stab at a generic data easyblock, but feel free to do this yourself if you're up for it.

in the meantime, i suggest to already go ahead with creating a separate easyconfig for RFdiffusion_data. you should be able to use the Bundle easyblock (which does not install anything), and download the models in a postinstallcmds, as you have done here.

[ThomasHoffmann77]

I'll have a look on RFdiffusion_data in the next few days. RFdiffusion-1.1.0_data_paths.patch requires an update allowing to read the models and schedules from elsewhere defined in a environment variable.

[pavelToman]

Hi! I juts start to work on vscentrum/vsc-software-stack#283 pipeline of RFdiffusion - ProteinMPNN -AlphaFold. I'd like to use RFd with data models either. Do you working on that or you stop?

[ThomasHoffmann77]

Hi! I juts start to work on vscentrum/vsc-software-stack#283 pipeline of RFdiffusion - ProteinMPNN -AlphaFold. I'd like to use RFd with data models either. Do you working on that or you stop?

@pavelToman I am currently working on AlphaFold/2.3.2-foss-2023a-CUDA-12.1.1. see also #19841

[pavelToman]

• {lib}[GCC/11.3.0,GCCcore/11.3.0] DGL v1.1.1, DLPack v0.8, DMLC-Core v0.5, ... w/ Python 3.10.4 #19095

[WilleBell]

This command will create two output directories in %(installdir)s, is there a way to avoid this?

[WilleBell]

Suggested change

	'cp -rpP config examples %s/%%(namelower)s' % _pysp,
	'cp -rpP config examples helper_scripts %s/%%(namelower)s' % _pysp,
	'cp -pP %%(namelower)s/inference/sym_rots.npz %s/%%(namelower)s/inference/' % _pysp,

RFdiffusion needs sym_rots.npz to perform symmetry operations which is needed to use different symmetry settings.

[garadar]

From https://github.com/easybuilders/easybuild-easyconfigs/pull/18359/files#diff-03d4d74a13067c23b1773097b070efb41c27ac715ad10f07b0fd98775ba1a144

    {
        'source_urls': ['https://github.com/KarypisLab/GKlib/archive'],
        'download_filename': 'METIS-v6.1.1-DistDGL-0.5.tar.gz',
        'filename': 'GKlib-METIS-v6.1.1-DistDGL-0.5.tar.gz',
        'extract_cmd': "tar -C %(namelower)s-%(version)s/third_party/METIS/GKlib --strip-components=2 -xf %s",
    },

It seems the source v6.1.1-DistDGL-0.5 is not available : https://github.com/KarypisLab/GKlib/tags