Add an option to turn-off disconnected components calculation

[thilinarmtb]

Stop finding the number of disconnected components in the generated partitions.
This takes a very long time when the number of disconnected components are in the
order of 100.

TODO

• Test the branch on a bigger mesh at scale before merging.

[stgeke]

Is the warning that there are many disconnected components?

[yslan]

For our chimera case (E=1.69Bn), it prints something like this and take a very long time

Warning: Lanczos reached a residual of 0.000014 (target: 0.000010) after 50 x 50 iterations in Level=15!
Warning: Partition created 1/1999 (min/max) disconnected components in Level=15!
parrsb_part_mesh_v0: restore original input
parRSB finished in 3261.12 seconds.

[thilinarmtb]

Is the warning that there are many disconnected components?

Yes, it takes a long time if there are a large number of disconnected components.

[stgeke]

I wanted to say that having no warning at all is also not a good option.

…

On 15 Apr 2024, at 21:25, Thilina Ratnayaka ***@***.***> wrote:  Is the warning that there are many disconnected components? Yes, it takes a long time if there are a large number of disconnected components. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[thilinarmtb]

What would be a good compromise? Shall we enable finding disconnected components
by default and then have an option to disable it if required?

[stgeke]

Yeah or we only turn it on for the first N levels.

[thilinarmtb]

@stgeke : I added an option to turn-off finding disconnected components if necessary. User can do:

export PARRSB_FIND_NUM_COMPONENTS=0

in order to turn it off. Or this can be set in in the parrsb_options struct when parRSB is called with
the C API.

[stgeke]

I find the name a bit confusing. How about renaming it to PARRSB_FIND_DISCONNECTED_COMPONENTS ?