Skip to content

Made necessary updates to the employment alignment#331

Merged
LiangShi369 merged 2 commits intodevelop_LS_PortEmploymentAlignmentfrom
MV-fix-EmploymentAlignment
Feb 3, 2026
Merged

Made necessary updates to the employment alignment#331
LiangShi369 merged 2 commits intodevelop_LS_PortEmploymentAlignmentfrom
MV-fix-EmploymentAlignment

Conversation

@Mariia-Var
Copy link
Copy Markdown
Collaborator

@Mariia-Var Mariia-Var commented Feb 1, 2026

-ensure ACMales, ACFemales and SingleDepMales, SingleDepFemales employment rates are aligned correctly

@LiangShi369, feel free to review the changes I made to employment alignment:
-included updated employment targets for 7 categories of BU (couples, singleMale, singleFemale, singleACMale, singleACFemale, SingleDepMales, SingleDepFemales)
-ensured we have alignment processes set up for these 7 categories of BU
-also, cleaned up some files and variable names

@justin-ven @Mariia-Var. I corrected typos in Statistics3 Class mentioned earlier, and all integration tests pass. I notice that during the alignment for some categories, the root finding procedure ends up with boundary solutions. Shall we worry about this at this stage? I can implement some checking and fix basing on the current version of model.

-ensure ACMales, ACFemales and SingleDepMlaes, SingleDepFemales employment rates are aligned correctly
@justin-ven
Copy link
Copy Markdown
Contributor

@Mariia-Var Boundary solutions are often an issue - I will add a new issue so that we can come back to this - well done!

@justin-ven justin-ven mentioned this pull request Feb 3, 2026
@Mariia-Var
Copy link
Copy Markdown
Collaborator Author

@justin-ven , @LiangShi369
The comment “the root finding procedure ends up with boundary solutions” was added by Liang.

Yes — that is exactly the issue I spent some time investigating. It seems to occur only when aligning employment for one BU category - SingleDepFemale, while it works fine for all other categories, including SingleDepMale.

At first, I thought I might have missed a typo, so I asked Liang to take a look as well. Probably he also didn’t find any possible error there..

I agree that we can create an issue and come back to it later; however, if Liang has any further ideas or checks in mind, it may still be worth trying them now.

@Mariia-Var
Copy link
Copy Markdown
Collaborator Author

@justin-ven , @LiangShi369
I think we can approve this PR, as it is merging "MV-fix-EmploymentAlignment" to "develop_LS_PortEmploymentAlignment". And once David finishes with the integration of the new estimates into the develop branch, we can then merge "develop_LS_PortEmploymentAlignment" into the develop.

@LiangShi369 LiangShi369 merged commit ba38ebf into develop_LS_PortEmploymentAlignment Feb 3, 2026
@LiangShi369
Copy link
Copy Markdown
Contributor

LiangShi369 commented Feb 4, 2026

@Mariia-Var @justin-ven I am investigating the boundary solutions in root searching. The cause is more than just typo -- solution requires some structural changes in activity alignment class. Will keep you updated. Meanwhile, shall we open another pull request or stay in this #331 ?

@LiangShi369 LiangShi369 deleted the MV-fix-EmploymentAlignment branch February 5, 2026 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants