本帖最后由 Hansha 于 2011-10-8 13:45 编辑
前天，Steve Jobs去世了，我出了一篇帖子，引用了他的这句话，作为对他的悼念。中文里对此也有类似的说法，不妨可以翻译成。 “求知若渴。大智若愚。”
事情是由我看到的一篇帖子引起的。说的是几个part被merge之后，原来赋予的属性都没了。原帖我就不引用了。我觉得这个问题应该有一定的共性，所以单独写这样一个帖子，谈谈我的一些看法，当我们遇到问题以后，应该怎么办。
有的网友，爱说自己是“菜鸟，小白”，来请教“大侠，高手”。他们倒未必是虚情假意的奉承，但在某种潜意识里，他们却会认为，我是对的，事情就该按照我的思路来进行。就拿那个例子来说吧，很显然，这个网友的潜意识里就认为，part被merge之后，各个part的属性是应该保留的，不应该失去。可实际情况是属性没了，于是就想不通，来论坛求助了。如果你确实有一点“求知若渴。大智若愚”的话，那么当你碰到这种情况，你首先的想法应该是“原来几个part被merge后，属性是要失去的”。你首先的做法应该是给各个部分重新赋予属性（又不难），把job送上去运行。空下来，再来琢磨这个事情。而不要一味纠缠在“它怎么就不。。。。。。呢？”。另外，他还认为，既然在merge前已经赋予了属性，那么再赋予一次，岂不是要重复了？那些个属性明明都已经没有了，怎么你还会在那里觉得会“重复”？难道那些个属性被藏在了某个地方，你不重新赋予，它们就不露声色，说没属性，你一旦重新赋予，它们就蹦出来和你唱对台戏，说你重复？
做事情要顺势利导，不能死犟。Abaqus是人家编写的，不可能处处按照你的意思行事。bug是有的，但毕竟很少。在绝大多数情况下，出了问题，是你错了，否则Abaqus早关门了。merge后属性没了，你凭什么说，属性不可以没有，必须保留？“大智若愚”不易做到，但我们至少不应该“大愚若智”吧？这样是要耽误事情的。
也许你的问题很简单，所以你会认为，应该这样，而不应该那样。merge后保留几个part的属性，有什么难呢？怎么就不给保留呢？但你要知道，Abaqus不是为了你的那个简单问题单独设计编写的，它面对的是形形色色，各种各样的复杂问题。很有可能，某个问题，在简单的情况下，不难解决，但当复杂到一定程度时，就没办法解决了。而是简单还是复杂，又很难用某个指标去衡量判断。这个时候，程序设计人员只好统一处理，摒弃某些功能。于是很不幸，你的那个简单问题，随着那些复杂问题，被一起摒弃了。
大家在学习，尝试，解决问题的过程中，思路要活一点，多问自己几个问题。必要时把问题记下来。即便一时没解决，但以后万一看到类似的问题，会有启发作用。我在看曹老师的那本“常见问题解答”时，曾看到5.3节（81页）讲的就是对多个部件实体进行布尔操作。对于提到的两个优点，当时就产生过问题：
优点1）不需要为相交区域定义绑定约束（tie），直接为合并后的新部件划分网格即可。我就想，如果在合并前就为部件划分了网格，会怎样呢？
优点2）不需要为多个部件逐个定义材料属性，只需为合并后的新部件定义一次材料属性即可。 我就想，如果各个部件的材料属性不一样，合并后，再分别定义，当然没问题。但能不能在合并前先分别定义了各个部件的材料属性呢？
所以，当我看到这个帖子时，我马上就把当时的问题想起来了。并且对第二个问题马上有了答案：part在合并前的定义的属性在合并后会消失。
另外，我们应该细致，再细致一点。那个网友还给了一个连接，说就是按照某个哥们的那个办法做的。我也去那个连接看了一下。结果看到，人家明明是先merge，然后再赋予属性的。粗心是任何人都会发生的。但要有意识地去尽量避免。一旦发生错误，就更应该细致地一步步检查。如果是沿用了别人的办法，就要把人家的办法拿来再看看，再对照，有何不同。先假设自己是错的，仔细检查。如果总假设自己是对的，那么就很难查出问题了。
我想大家会理解，我这个帖子不针对任何人。只是希望大家，包括我在内，把事情做得更好。最后，还是以这两句话作为结束吧：
Stay hungry. Stay foolish.
| 
IP卡
狗仔卡
发表于 2011-10-9 02:38:24
提升卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
发表于 2011-10-11 16:16:07
