[讨论]想统计一下有多少人自己写 FDTD 3D 代码做仿真

想统计一下有多少人自己写 FDTD 3D 代码 .. 0j-;4>p  
Q0_|?]v  

未注册仅能浏览部分内容，查看全部内容及附件请先 登录 或 注册

我写了一个月的三维PML，但一直没调通，后来就放弃了，论坛里找了一个现成的三维PML，

做算法一般都要写吧

如果每个模块都要自己写，岂不是很痛苦。 ^H1B62_  
论坛上3D的代码也看了一些。感觉可重复使用性不好，不够模块化。没法移植到自己的代码中。

恩，如果是科研的话，还是要自己动手写。 60B6~@]P  
真正写的很好的，估计也是因为项目等原因，不会轻易公开发布到网上的。

忙里偷闲，也来说说自己写3D代码时的一些体会吧， 算是抛砖引玉。 /a}F;^  
OT[&a6_  
通常我在写代码之前，会把相关的paper仔细读一读。对算法本身理解清楚，避免在这上面犯错误。有时侯我也对paper中从具体物理原理到算法的推导过程比较糊涂，但这似乎不影响对算法的理解。我的感觉是很多算法本身不难，难的是如何正确的从算法到代码的转换过程。 `52+.*J+%  
算法搞清楚后最好能在1D的情况验证一下。1D的代码简单易于debug，能够把对算法理解的问题暴露出来。保证算法在代码实现过程中的正确性。1D的程序能够成功运行后，可以着手准备2D－TE（TM）。仔细分析自己的1D代码，尽最大可能的使代码模块化。一个算法包含若干步奏，其实很多步奏基本相同，只有些许差异。最好写一个通用的函数来实现他们，用一个变量来控制这些差异。这样程序的可靠性就高一些。从1D 扩展到 2D，3D的过程中，最容易出bug的地方是各个变量的索引。举个例子，你本意是想在Ex(100,120,103)加一个损耗，结果你把这个损耗加在了Ex(100,130,103)上面。上面这个bug一眼就能看出来那时因为索引直接是用数字写出来的。在实际的代码中，索引是一些变量。这样这个bug就很好的隐藏起来了。并且你自己制造了这个bug，你还对它熟视无睹。运气好的时候这样的bug直接使你的程序爆掉，这样你还能一点一点的从代码中找出来。要是运气不好，你的程序照样跑，你还不知道它的存在。其结果就是你的仿真结果精度有问题或者根本就是错误的，但是你还很高兴以为是对的。其实排查这中bug最有效的办法（我个人认为）就是仔细分析结果。自己的结果要匹配paper上的才行。 )YE3n-~7{  
从2D到3D的过程是痛苦的。准备工作也要做足。首先是画图，把你想干的活清清楚楚的在图上画出来。没有图就想把代码写正确，那你的智商要很高才行。有了图，以后在排错的时候也会方便许多。图画好以后也可以简单的写一下步奏，作为图的补充。接下来就开始写代码。还是那句话，索引容易出bug。所以慢慢写，不着急。着急写代码省不了时间，反而会在debug的时候加倍付出的，在3D这种情况下会指数倍的付出。 WZ\bm$  
>?/Pl"{b