Describe the bug
The current IPF is based on a fork of the https://github.com/Dirguis/ipfn repository. We have observed that even with rate_tolerance=0 and convrgence_rate=0 the IPF process will say it has converged although the marginal controls do not always perfectly match the marginals of the output.
To Reproduce
#174 proves this as there is no way for the IPF to converge in that situation although the output tuple with verbose=2 will indicate it has converged.
Expected behavior
The IPF process should indicate non-convergence if input parameters indicate exact matching only.
Potential resolution
@Eric-Liu-SANDAG has implemented an internal IPF process that we can use to replace the current IPF process throughout the project
- Remove references and usage of funcations from the
ipfn package. This is is currently only used in two places, both in python/ase.py and is specified as in the environment.yml file.
- Replace the
ipfn.pfn.ipfn() function with internally developed process
- Run an end-to-end run that mimics the Estimates 2024 run for us to compare to
Describe the bug
The current IPF is based on a fork of the https://github.com/Dirguis/ipfn repository. We have observed that even with
rate_tolerance=0andconvrgence_rate=0the IPF process will say it has converged although the marginal controls do not always perfectly match the marginals of the output.To Reproduce
#174 proves this as there is no way for the IPF to converge in that situation although the output tuple with
verbose=2will indicate it has converged.Expected behavior
The IPF process should indicate non-convergence if input parameters indicate exact matching only.
Potential resolution
@Eric-Liu-SANDAG has implemented an internal IPF process that we can use to replace the current IPF process throughout the project
ipfnpackage. This is is currently only used in two places, both inpython/ase.pyand is specified as in theenvironment.ymlfile.ipfn.pfn.ipfn()function with internally developed process