Add WeightingInterface link to SolverInterface

[GiovanniCanali]

Description

This PR fixes #619.

This PR also adds the SelfAdaptiveWeighting class. Reference (page 9): https://arxiv.org/pdf/2507.08972.
Moreover, it introduces the possibility to update weights via the update_and_aggregate and _update methods.

Checklist

• Code follows the project’s Code Style Guidelines
• Tests have been added or updated
• Documentation has been updated if necessary
• Pull request is linked to an open issue

[dario-coscia]

Hi @GiovanniCanali! I was having a look at this even tho it is not marked as review yet.

I like your changes! One thing I would try is to add a kwarg (e.g. update_every_nepoch or something similar) to all methodologies where the values of the weights are updated (ofc this doesn't change the "static" weightings). A simple way to achieve this is to put it in the init of weighting interface. Then we can make a method in the same class (e.g. update_and_aggregate or something similar) which we simply overload aggregate and call it if trainer.current_epoch% update_every_nepoch==0. This method is also called in the solver in _optimization_cycle instead of the current aggregate. What do you think?

[GiovanniCanali]

Hi @GiovanniCanali! I was having a look at this even tho it is not marked as review yet.

I like your changes! One thing I would try is to add a kwarg (e.g. update_every_nepoch or something similar) to all methodologies where the values of the weights are updated (ofc this doesn't change the "static" weightings). A simple way to achieve this is to put it in the init of weighting interface. Then we can make a method in the same class (e.g. update_and_aggregate or something similar) which we simply overload aggregate and call it if trainer.current_epoch% update_every_nepoch==0. This method is also called in the solver in _optimization_cycle instead of the current aggregate. What do you think?

I agree with you. I just need to think a bit about the changes with respect to the solver, but it should not be a big deal.

[dario-coscia]

I agree with you. I just need to think a bit about the changes with respect to the solver, but it should not be a big deal.

I think we just need to change this line https://github.com/mathLab/PINA/blob/master/pina/solver/solver.py#L252 with the new update method which overloads aggregate

[dario-coscia]

@GiovanniCanali For me is ready, let me know what you think about it!

[dario-coscia]

@GiovanniCanali I see some tests are failing. This is because some solvers override _optimization_cycle. That's not something it supposed to happen. Maybe we can modify those bugs now, merge the PR in dev and update those solvers such that _optimization_cycle is only in solverinterface

[GiovanniCanali]

Great @dario-coscia, everything looks good to me.

I just highlighted some minor issues related to the documentation, let's fix them before merging!

[GiovanniCanali]

Hi @dario-coscia,

This PR is now complete and ready for review. Commits have been squashed, so that we now have one commit per new feature.

Tests are failing due to #621. I would suggest fixing that issue before merging, so we can also check that the tests pass on Ubuntu and macOS.