关于Python in schudule中几点总结和建议

JoyLin

最近有个课题，用到了Python in schudule，感觉还是很强大的，这里提出几个应用建议。
水平有限，还请斧正。
1、关于ARR自定义静态属性
arithmetic中是不能读取使用ARR的，但是python in schedule 的grid_arithmetic函数却可以。
不知道是bug，还是有意为之，总之很好用，点个赞，希望不是bug，以后能继续使用。
如果可以创建自定义动态属性，那就厉害了，可惜现在不能。
2、关于grid_arithmetic中可修改属性
还是太少，如果覆盖相渗端点、启动压力梯度等属性，就更加强大了。
这里python修改grid属性，还需要借用arithmetic公式，开始不理解，不过后来觉得应该是处于性能考虑吧。
希望后期能有python语言原生的修改功能，这样，像cell(i)-cell(i-1)的编辑功能就能实现了，同时像numpy等库也可以应用于grid属性的计算了。
3、关于__init_script__函数
这个函数的运行时机，手册中只是说在脚本初始化里，可以里边的print函数、全局变量都无效
开始以为有问题，分析认为其初始化时机是data加载时，data加载时运行__init_script__函数后，脚本关闭，全局变量会失效。
为什么create_graph函数会生效，因为其操作的是tnav内部变量，变量的生命周期大于脚本的生命周期。

4、关于脚本的全局变量
函数体外的全局变量，不管你加不加global，都是无法正常访问的，原因分析：
其实python的global不是严格意义上的全局变量，类似C++中的文件static变量或者const变量，应该叫文件作用域变量
分析认为，tnav每个时间步都是重新载入py文件，运行完毕后再关闭，所以全部文件作用域在每个时间步都会重新初始化(见附图)

强烈建议增加set_global、get_global函数，可以设置、读取真正的全局变量，感觉很有用
比如在脚本运行前，我要加载一个保存数据的xlsx，并保存在全局变量里，每个时间步脚本运行时，读取全局变量
5、tnav的API是不能出现在自定义模块中的
可能表达不清，比如我写了一个模块，里边用了tnav的api，再在schedule的python脚本中调用这个模块
模拟器会提示，某块中的API是不存在的，也就是tnav的api只能出现在你的APPLYSCRIPT中py文件内
猜测，tnav的api采用运行时注入依赖的方式运行，自定义模块无法注入依赖，所以Python找不到api
6、关于Graph值计算的问题
Graph计算时，只要表达式中有graph类型的变量，那么结果就是graph类型，而不是数值类型，
比如 a = wbhp[well] + 10 , 这里的a也成为graph类型，而graph类型没有实现__format__，
所以在格式化format中直接使用变量a 会报错，应该进行显示转换float(a)，或者str(a)。

7、关于部署发布的问题
建议将私有算法编译为pyd模块，提供用户接口py文件，同时可以将pyd模块加入到python解释器的嵌入版里，一起提供给用户
直接在tnav加入python路径，应用接口py文件即可。
8、未来展望
希望能将python in schedule发展成一个插件系统，可以将插件系统做成一个标准的pip包
利用面向对象的多态性，可以在不同的阶段调用插件算法，比如加载data时，读取grid结束后，甚至读取到某个关键时
同时有利于调试，现在的调试基本靠print，有点难受
希望tnav成为自定义程度最高的模拟器，不管在科研还是矿场中都是一把无双利器！

乔聪颖

写在前面：

楼主的总结和建议很深入也很有远见，在此表示感谢！

本人并未参与Python in schedule功能的研发设计，仅以普通用户视角和大家一起分享、讨论，难免不足，欢迎斧正。

针对楼主所提问题的解答：

1、关于ARR自定义静态属性

并非bug。在Python in schedule设计之初并没有考虑调用ARR，因为设计该功能的主要目的之一是替代Action+UDQ的功能，并不涉及（或很少涉及）属性场的调用。

另外，Python in schedule支持第三方库的调用，手册中有，相信楼主看到过，不想麻烦的话，可以参直接考论坛帖子“tNavigator-Python应用-盘点新释放的21.1版内嵌了哪些新的第三方库”。

2、关于grid_arithmetic中可修改属性

grid_arithmetic是在有针对属性场调用的需求后添加的功能。

“python语言原生的修改功能”方面确实还不算太完善，不过就像很多前沿技术一样，都会随着需求的变化而不断迭代，以需求为导向可能更普遍。

所以非常希望大家多提具体需求，集思广益，合理的、面向切实需求的、能难倒现有技术的问题才是真正的好问题！

3、关于__init_script__函数

当前__init_script__中仅支持使用一个API - create_graph()，而graph是存在于整个模型运算过程中的，类似于UDQ，所以楼主的理解是对的。

4、关于脚本的全局变量

原因确实如楼主所推测的那样。

其实在Python in schedule功能刚释放不久我即向研发人员反馈过，在找到简易替代方式后，暂时未考虑补上“全局变量”的功能。

当前替代方式主要有两个，Python in schedule中可自主控制的__init_script__函数以及时间、脚本执行次数等，即可以依据上面两个内容作为判断依据（类似全局变量），自主设计，供参考。

5、tnav的API是不能出现在自定义模块中的

楼主描述的现象确实存在，我当前也不能确定原因。

6、关于Graph值计算的问题

楼主描述的现象其实可以通过“先给变量赋值，然后使用表达式”来解决。

7、关于部署发布的问题

很好的建议，我们会反馈给开发人员。

8、未来展望

感谢楼主的建议与期待！我个人也非常期待tNavigator中能够包含一个（多个）高开放度的插件系统，能够深度满足各类需求。