Solver的训练能否支持early_stop

[pecanjk]

需求描述 Feature Description

RT。目前高阶求解器支持的不多且不是很好用，Adam等求解器往往训练很久

替代实现 Alternatives

No response

[HydrogenSulfate]

感谢你的建议，想进一步了解一下你需要的early_stop 是由什么决定的？能具体描述一下吗

[pecanjk]

感谢你的建议，想进一步了解一下你需要的early_stop 是由什么决定的？能具体描述一下吗

主要是在3D场景中需要大量采样和长时间的迭代（有的要训几天），而往往设置迭代时间过长之后，后期loss其实不怎么降的，可以提前结束的。特别是Adam求解器是这样的。如何是含时的3D场景，训练更加不稳定，采样和迭代时间会更长

另外在biharmonic2d无法复现这个里面，由于L-BFGS这个二阶优化器我这无法优化，我尝试把Adam迭代时间拉很长，才能勉强得到好点的结果。

[HydrogenSulfate]

感谢你的建议，想进一步了解一下你需要的early_stop 是由什么决定的？能具体描述一下吗

主要是在3D场景中需要大量采样和长时间的迭代（有的要训几天），而往往设置迭代时间过长之后，后期loss其实不怎么降的，可以提前结束的。特别是Adam求解器是这样的。如何是含时的3D场景，训练更加不稳定，采样和迭代时间会更长

另外在biharmonic2d无法复现这个里面，由于L-BFGS这个二阶优化器我这无法优化，我尝试把Adam迭代时间拉很长，才能勉强得到好点的结果。

1. 所以你说的【loss不怎么降低，提前结束】，是指通过判断训练loss的某些统计指标来达到提前退出的目的吗？
2. 可以试试近期支持的SOAP优化器，在一些PINN的场景下收敛速度和精度比adam要好一些，另外L-BFGS的问题我们还在排查中。

[pecanjk]

感谢你的建议，想进一步了解一下你需要的early_stop 是由什么决定的？能具体描述一下吗

主要是在3D场景中需要大量采样和长时间的迭代（有的要训几天），而往往设置迭代时间过长之后，后期loss其实不怎么降的，可以提前结束的。特别是Adam求解器是这样的。如何是含时的3D场景，训练更加不稳定，采样和迭代时间会更长
另外在biharmonic2d无法复现这个里面，由于L-BFGS这个二阶优化器我这无法优化，我尝试把Adam迭代时间拉很长，才能勉强得到好点的结果。

1. 所以你说的【loss不怎么降低，提前结束】，是指通过判断训练loss的某些统计指标来达到提前退出的目的吗？

2. 可以试试近期支持的[SOAP](https://paddlescience-docs.readthedocs.io/zh-cn/latest/zh/api/optimizer/#ppsci.optimizer.optimizer.SOAP)优化器，在一些PINN的场景下收敛速度和精度比adam要好一些，另外L-BFGS的问题我们还在排查中。

1. 是的，或者仅仅看loss是否有进一步降低，没有的话就early_stop。另外还有某些scheduler也可以做到这点, 例如torch.optim.lr_scheduler.ReduceLROnPlateau(optimizer, factor=0.2, min_lr=1e-8, patience=300, verbose=True)里的patience

[HydrogenSulfate]

感谢你的建议，想进一步了解一下你需要的early_stop 是由什么决定的？能具体描述一下吗

主要是在3D场景中需要大量采样和长时间的迭代（有的要训几天），而往往设置迭代时间过长之后，后期loss其实不怎么降的，可以提前结束的。特别是Adam求解器是这样的。如何是含时的3D场景，训练更加不稳定，采样和迭代时间会更长
另外在biharmonic2d无法复现这个里面，由于L-BFGS这个二阶优化器我这无法优化，我尝试把Adam迭代时间拉很长，才能勉强得到好点的结果。

1. 所以你说的【loss不怎么降低，提前结束】，是指通过判断训练loss的某些统计指标来达到提前退出的目的吗？

2. 可以试试近期支持的[SOAP](https://paddlescience-docs.readthedocs.io/zh-cn/latest/zh/api/optimizer/#ppsci.optimizer.optimizer.SOAP)优化器，在一些PINN的场景下收敛速度和精度比adam要好一些，另外L-BFGS的问题我们还在排查中。

1. 是的，或者仅仅看loss是否有进一步降低，没有的话就early_stop。另外还有某些scheduler也可以做到这点, 例如torch.optim.lr_scheduler.ReduceLROnPlateau(optimizer, factor=0.2, min_lr=1e-8, patience=300, verbose=True)里的patience

ppsci.Solver下的相关代码，主要考虑通用性以及大部分开源算法固定训练轮数而不使用early stop，其涉及到比较精细、定制化的（每个人、每个训练任务的都可能不同）的训练控制，故当时设计ppsci时，就不考虑支持early stop（否则可能造成源码的分支太多，可读性降低）。

1. 建议直接手动尝试不同的训练轮数，根据表现确定一个大概的训练轮数即可。
2. 即便不使用ppsci.solver，ppsci下的一些模块仍然是可复用的，比如logger、save_load、config，这些模块能够放到自己手写的代码中而不依赖其它ppsci的组件
3. 如果你有好的、兼容、简单的实现或支持想法，可以在这个PR里讨论，如果足够简单可以考虑支持