NumCosmoDataClusterWLFactor

Cluster weak-lensing likelihood built on the per-galaxy Factor calculators (NcGalaxyPositionFactor / NcGalaxyRedshiftFactor / NcGalaxyShapeFactor).

The likelihood factor per galaxy is $$P(\epsilon_\mathrm{obs} \mid g) = \int_{|\chi_I|<1} \mathrm{d}^2\chi_I\, P_\mathrm{pop}(\chi_I)\, N_2\big(\epsilon_\mathrm{obs} - f_g(\chi_I); \sigma_\mathrm{noise}^2\big),$$ combined multiplicatively with the position and joint-redshift factors and integrated once over the source redshift $z$ — exactly NcGalaxyRedshiftFactor‘s documented contract (“the calculator never integrates $z$ itself; the orchestrator integrates this against every other $z$-dependent factor”).

Supports three redshift-integral methods: LNINT (default, adaptive log-domain 1D), FIXED_NODES (fixed Gauss-Legendre, with an optional per-galaxy auto-nodes calibration — see nc_data_cluster_wl_factor_set_auto_nodes()) and CUBATURE (adaptive NcmIntegralND over the linear-domain product). All three are mathematically exact, differing only in numerical strategy/cost, and all three support bootstrap resampling. No OpenMP parallelism yet (including for auto-nodes calibration, which stays serial): deferred, since it needs per-thread duplication of the (currently prepare()-shared, mutable) integrator/integrand state before it can be added safely — see the class’s own git history for the planning notes. No fit-time r_min/r_max weighting: applying it biases the mass estimate.

Design principle followed throughout: all preparation work happens in prepare() — resolving models, refreshing each Factor’s own caches, re-preparing the z-integrands — so m2lnL_val() and resample() only use already-prepared state. The three Factor objects are held as direct, construct-only references (confirmed the intended pattern: calculators are designed to be held and shared across likelihoods); this orchestrator never computes a Factor’s change-detection hash itself, never calls ncm_model_state_get_pkey(), and never knows which NcmModels a given Factor depends on — it only compares the opaque guint64 values each Factor’s own prepare() call produces. See the three Factor classes’ own documentation for the get_hash()/update_data() contract this relies on.