I agree to divide conditions in multiple classes but I do not think that the residual method should be inside conditions. I see conditions more like an object that encapsulates data, if we constrain also to what the model should do we can't cover all test cases. I think that the loss to minimize should be defined only inside the solver (physics-informed, data-driven whatever), in this way is user responsibility to know how to use the data
Maybe we can think more of something like PhysicsConditions, DataConditions, GraphConditions (like the division in the dataloading)... These conditions are needed to call loss_data, loss_phys, and loss_graph (which are defined inside the solver). This helps us to do two things:
We know which functions need to be defined in the solver by looking at the conditions the problem has (we can raise errors before training)
We don't need to cover all classes of possible ways residuals are defined, we only need to pass the data that are needed to compute it.
I agree to divide conditions in multiple classes but I do not think that the
residualmethod should be inside conditions. I see conditions more like an object that encapsulates data, if we constrain also to what the model should do we can't cover all test cases. I think that the loss to minimize should be defined only inside the solver (physics-informed, data-driven whatever), in this way is user responsibility to know how to use the dataMaybe we can think more of something like PhysicsConditions, DataConditions, GraphConditions (like the division in the dataloading)... These conditions are needed to call loss_data, loss_phys, and loss_graph (which are defined inside the solver). This helps us to do two things:
_Originally posted by @dario-coscia in https://github.com/mathLab/PINA/pull/312#discussion_r1730291720_