Different Conditions

[dario-coscia]

At the moment PINA offers only Condition as a class that takes as input input_points/output_points, input_points/equation, location/output_points, location/equation.

In this framework, it is not possible to write periodic boundary conditions... There is the PeriodicBoundaryEmbedding in PINA which is a nice workaround, but it is not the same as implementing a soft loss. It would be nice to have PeriodicConditions or, more in general, ConditionsInterface so that the user can define its own condition. What do you think?

[ndem0]

I completely agree! Also, we can use the Condition approach to simplify the training loop, at the moment quite complicated to understand!
I'll report here the snippet in PINNInterface:

        for condition_id in range(condition_idx.min(), condition_idx.max() + 1):

            condition_name = self._dataloader.condition_names[condition_id]
            condition = self.problem.conditions[condition_name]
            pts = batch["pts"]
            # condition name is logged (if logs enabled)
            self.__logged_metric = condition_name

            if len(batch) == 2:
                samples = pts[condition_idx == condition_id]
                loss = self.loss_phys(samples, condition.equation)
            elif len(batch) == 3:
                samples = pts[condition_idx == condition_id]
                ground_truth = batch["output"][condition_idx == condition_id]
                loss = self.loss_data(samples, ground_truth)
            else:
                raise ValueError("Batch size not supported")

            # add condition losses for each epoch
            condition_losses.append(loss * condition.data_weight)

I would add the evaluate (or error, or whatever) method to all the Conditions, such that it will be possible, hopefully, to refactor the train like:

for condition, samples_condition in zip(self.conditions, batch):
    loss = condition.evaluate(sample_condition)

The classes so to have are:

• ConditionInterface: the abstract base class
• DataCondition: the input-output condition
• PhysicsCondition: the equation based
• EqualityCondition: condition to impose (weak way) equality between different domains
• PeriodicCondition: just an alias referring to the previous one, just for completeness
• Condition: a factory class (https://en.wikipedia.org/wiki/Factory_method_pattern) for making users life easier and for retrocompatibility.
• something else?

What do you think? Do you see any criticality?

[dario-coscia]

I completely agree, this looks very helpful for future maintenance! Will the user use only Condition for back compatibility or does he need to specify the types of conditions in the problem?