Implementing the Flow Logic for Carmel
1Introduction
In[4]a control?ow analysis for Carmel is speci?ed and proved correct with respect to the semantics as de?ned in[9].The Carmel language is described in detail in[6,9].Extensions to the basic control?ow analysis are discussed in[3]; we shall not go into further detail with the control?ow analysis or the extensions of it here.In this paper we show how the?ow logic speci?cation given in[4] systematically can be transformed into a speci?cation for generating constraints in the Alternation-free Least Fixed-point logic(ALFP).Constraints over this language can be solved using the techniques described in[8,7],in particular they can be solved using the“Succinct Solver”of Nielson and Seidl.
The transformation is,deliberately,kept in a“high-level”style that is very close to that of the Flow Logic speci?cation.This is in part to facilitate the proof of semantic correctness for the transformation and also in part to simplify the transformation process.This comes at the price of lower e?ciency,with respect to both time and space,when solving the generated constraints.In Section6a number of strategies for optimising the constraint generation are discussed.
The remainder of the paper is structured as follows.Section2introduces the Alternation-free Least Fixed-Point(ALFP)logic in more detail.Section3 details how the abstract domains are represented as ALFP constraints and Sec-tion4then shows how the Flow Logic speci?cation is converted into ALFP constraints;this includes a full speci?cation of the constraint generation for all the supported instructions.Semantic correctness of the conversion from Flow Logic to ALFP is discussed in Section5.A number of optimisation strate-gies regarding the generated constraints are described in Section6and then in Section7we give an overview of a prototype implementation of the constraint generator.Conclusions and Future Work can be found in Section8.
2Alternation-free Least Fixed-Point logic
The fundamental idea in implementing the analysis of[4]is to convert the?ow logic clauses to clauses in the Alternation-free Least Fixed-Point(ALFP)logic, because e?cient means for?nding solutions to ALFP clauses are well known, such as the Succinct Solver technology,cf.[7,8].In the following we give a brief introduction to the ALFP logic.
1
2.1The constraint Language
Formulae in ALFP consists of clauses of the following form:
pre::=R(x1,...,x k)|pre1∧pre2|pre1∨pre2|?x:pre clause::=R(x1,...,x k)|1|clause1∧clause2
|pre?clause|?x:clause
where R is a k-ary relation symbol for k≥1and x1,...denote variables while 1is the always true clause.
In the following let t be a pre-condition or a clause.Then for a given universe, U,of atomic values,and interpretationsρfor relation symbols andσfor free variables,the satisfaction relation for pre-conditions and clauses,(ρ,σ)|=ALFP t, can be de?ned as follows:
(ρ,σ)|=ALFP1i?true
(ρ,σ)|=ALFP R(x1,...,x k)i?(σx1,...,σx k)∈ρR
(ρ,σ)|=ALFP?x:pre i?(ρ,σ[x→a])|=ALFP pre for some a∈U (ρ,σ)|=ALFP?x:t i?(ρ,σ[x→a])|=ALFP t for all a∈U (ρ,σ)|=ALFP t1∧t2i?(ρ,σ)|=ALFP t1and(ρ,σ)|=ALFP t2 (ρ,σ)|=ALFP pre1∨pre2i?(ρ,σ)|=ALFP pre1or(ρ,σ)|=ALFP pre2 (ρ,σ)|=ALFP pre?cl i?(ρ,σ)|=ALFP cl whenever(ρ,σ)|=ALFP pre For a given interpretation,σ,of variable symbols we call an interpretation,ρ, of relation symbols a solution to a clause clause if indeed(ρ,σ)|=ALFP clause.
2.2Solving the Constraints
Using the techniques of[7]it is possible to e?ciently?nd solutions to given clauses.An implementation,called Succinct Solver,using these and other ad-vanced techniques has been made by Nielson and Seidl and is described in[8]. 3Representing the Abstract Domains
This section is devoted to showing how the abstract domains used in the control ?ow analysis can be represented in the constraint language.
Basic values.For the pure control?ow analysis,integers are modeled as a single token:INT.For a simple data?ow analysis,this can easily be extended to a single token for each constant integer,v,occurring in the program:INT v and a top-element to represent“unknown”:INT .
Object references modeled simply as classnames:an object reference to a class classname is represented by cl
t.
Stacks.In order to model the abstract stack we use a quarternary relation, S,relating adresses and stack positions to values,thus the clause
S(m0,pc0,[3],INT)
SECSAFE-IMM-004-1.02
is intended to mean that the abstract stack at address(m0,pc0)contains an integer value at stack position three.
Since we must be able to manipulate and calculate stack positions directly within the clauses,stack positions must be represented explicitly:
[0]=zero
[n+1]=suc([n])
Instead of constructing numbers,as described above,special constants could be used to directly encode numbers,eg.int
3to mean the local variable at index3.
Again we use a quarternary relation to relate addresses and variable index to values:
L(m0,pc0,var
σ,f.id,v)
SECSAFE-IMM-004-1.03
Since the array is used for both objects and arrays,we use a“dummy”value, ARRAY,to di?erentiate between the two uses.Thus if?H(Ref(array t))= {INT}then
H(ar
σ,mv)
The constraints de?ning the relation ML are derived directly from the class hierarchy.
End Tokens.The special tokens occurring in addresses indicating the end of a method,used for transferring return values from methods,are represented as constants in the constraint language.A special relation then relates such constants to the method whose end token they represent:
END(m,end
m now represents the end token for the method represented by m.The relation can then be used for looking up the particular end token for a given method.In certain situations the end token need not be looked up but can be computed directly;in such cases we write END m for the token belonging to method m.
Like the ML relation,the END relation depends trivially on the structure of programs and therefore it is de?ned from the outset rather than solved for.
4Generating Constraints
In this section we show how to systematically transform the?ow logic spec-i?cation of the analysis,cf.[4],into another?ow logic speci?cation based on https://www.doczj.com/doc/838667261.html,ing the Succinct Solver technology,cf.Section2.2,we can e?ciently ?nd solutions to ALFP clauses and thereby obtain an implementation of the control?ow analysis.
We?rst present and discuss the new speci?cation in detail for a few represen-tative instructions(Section4.1),followed by the full speci?cation(Section4.2). SECSAFE-IMM-004-1.04
4.1A Few Interesting Clauses
4.1.1The push Instruction
For the push-instruction the?ow logic speci?cation is given as follows:
(?K,?H,?L,?S)|=(m0,pc0):push t v
i?{v}::?S(m0,pc0) ?S(m0,pc0+1)
?L(m
,pc0) ?L(m0,pc0+1)
This entails that the value being pushed,v,should be put on top of the stack, ie.in position zero,in the stack for the next instruction at pc0+1:
S(m0,pc0+1,[0],INT)
Note that the actual value,v,is replaced by a single token INT as we do not track the actual values in the control?ow analysis.
Furthermore,the entire stack for the current instruction(before the push-instruction is executed)must be copied to the instruction at pc0+1but moved one stack position down,eg.what was in position[0]should be copied to position [1],this is accomplished by the clause below:
?i:?a:?y:(y=[i+1])∧S(m0,pc0,[i],a)?S(m0,pc0+1,y,a)
While the above clause is a very straightforward translation of the Flow Logic speci?cation,it is quite expensive in terms of both time and space.In Section6 a number of optimisation strategies for improving this situation are discussed.
Finally,the local variables are untouched and thus copied forward unchanged:?x?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
putting all of the above clauses together,we arrive at:
(K,H,L,S)|=CG(m0,pc0):push t v i?
S(m0,pc0+1,[0],INT)
?i:?a:?y:(y=[i+1])∧S(m0,pc0,[i],a)?S(m0,pc0+1,y,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
4.1.2The store Instruction
The store-instruction is analysed as follows
(?K,?H,?L,?S)|=(m0,pc0):store t x
i?A::X ?S(m0,pc0):
X ?S(m0,pc0+1)
A ?L(m0,pc0+1)(x)
?L(m
,pc0) {x}?L(m0,pc0+1)
Intuitively A::X ?S(m0,pc0)is a binding operator,in that it binds whatever is on top of the abstract stack at the current address to the variable A,which can then be referenced in a later clause.For a more thorough explanation of the speci?cation and the notation used see[4].
SECSAFE-IMM-004-1.05
Following the above speci?cation we see that the values on top of the stack should be copied to the local variable x,this gives rise to the following con-straints:
?a:S(m0,pc0,[0],a)?L(m0,pc0+1,var
x.
Next the remainder of the stack must be moved one place,as the top of the stack is popped after having been copied.This is formulated in the constraint language using the following clause:
?i:?a:?y:(y=[i+1])∧S(m0,pc0,y,a)?S(m0,pc0+1,[i],a)
Having moved the stack into place,we now must copy all the local variables onwards,except the variable x which has just been updated and thus we need not copy the old value for x forwards:
?y:?a:(y=var
x,a)
?i:?a:?y:(y=[i+1])∧S(m0,pc0,y,a)?S(m0,pc0+1,[i],a)
?y:?a:(y=var
Combining the above constraints we can formulate the clause for putfield: (K,H,L,S)|=CG(m0,pc0):putfield f i?
?r:?a:S(m0,pc0,[1],r)∧S(m0,pc0,[0],a)?H(r,f,a)
?y:?a:?i:y=[i+2]∧S(m0,pc0,y,a)?S(m0,pc0+1,[i],a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
4.1.4The invokevirtual Instruction
Converting the speci?cation for invokevirtual follows the same general pat-tern as above although it is a bit more involved.First we recall the?ow logic speci?cation for invokevirtual:
(?K,?H,?L,?S)|=(m0,pc0):invokevirtual m
i?A1::···::A|m|::B::X ?S(m0,pc0):
?(Refσ )∈B:
m v=methodLookup(m.id,σ )
{(Refσ )}::A1::···::A|m| ?L(m v,1)[0..|m v|]
m.returnType=void?
T::Y ?S(m v,END m v):T::X ?S(m0,pc0+1)
m.returnType=void?
X ?S(m0,pc0+1)
?L(m
,pc0) ?L(m0,pc0+1)
First the reference to the object where the invoked method resides is copied(as a self reference)to local variable0of the invoked method:
?r?mv:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)?L(mv,1,var
1,a)
..
.
?r?mv?a:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧
S(m0,pc0,[|m|?1],a)?L(mv,1,var
Finally,since the local variables of the invoking method are not modi?ed,they are simply copied along as well:
?x?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
Putting it all together we arrive at:
(K,H,L,S)|=CG(m0,pc0):invokevirtual m i?
?r:?mv:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)?
L(mv,1,var
1,a)
..
.
?r:?mv:?a:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧
S(m0,pc0,[|m|?1],a)?L(mv,1,var
(K,H,L,S)|=CG(m0,pc0):swap m n i?
?a:S(m0,pc0,[0],a)?S(m0,pc0+1,[n],a)
..
.
?a:S(m0,pc0,[m?1],a)?S(m0,pc0+1,[(m?1)+n],a)
?a:S(m0,pc0,[m],a)?S(m0,pc0+1,[0],a)
..
.
?a:S(m0,pc0,[(n?1)+m],a)?S(m0,pc0+1,[n?1],a)
?y:?z:?i:?a:y=[i+n+m]∧z=[i+n+m]∧S(m0,pc0,y,a)?
S(m0,pc0+1,z,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
Arithmetic operators.
(K,H,L,S)|=CG(m0,pc0):numop t unop t opt i?
S(m0,pc0+1,[0],INT)
?y:?z:?i:?a:y=[i+1]∧z=[i+1]∧S(m0,pc0,y,a)?
S(m0,pc0+1,z,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
(K,H,L,S)|=CG(m0,pc0):numop t binop t opt i?
S(m0,pc0+1,[0],INT)
?y:?z:?i:?a:y=[i+2]∧z=[i+1]∧S(m0,pc0,y,a)?
S(m0,pc0+1,z,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
Control?ow.
(K,H,L,S)|=CG(m0,pc0):goto L i?
?i:?a:S(m0,pc0,[i],a)?S(m0,L,[i],a)
?x:?a:L(m0,pc0,x,a)?L(m0,L,x,a)
(K,H,L,S)|=CG(m0,pc0):if t cmpop goto L i?
?y:?i:?a:y=[i+2]∧S(m0,pc0,y,a)?S(m0,pc0+1,[i],a)
?y:?i:?a:y=[i+2]∧S(m0,pc0,y,a)?S(m0,L,[i],a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
?x:?a:L(m0,pc0,x,a)?L(m0,L,x,a)
(K,H,L,S)|=CG(m0,pc0):if t cmpop nullCmp goto L i?
?y:?i:?a:y=[i+1]∧S(m0,pc0,y,a)?S(m0,pc0+1,[i],a)
?y:?i:?a:y=[i+1]∧S(m0,pc0,y,a)?S(m0,L,[i],a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
?x:?a:L(m0,pc0,x,a)?L(m0,L,x,a)
(K,H,L,S)|=CG(m0,pc0):lookupswitch t(k i=>L i)n1,default=>L0i??y:?i:?a:y=[i+1]∧S(m0,pc0,y,a)?S(m0,L0,[i],a)
..
.
?y:?i:?a:y=[i+1]∧S(m0,pc0,y,a)?S(m0,L n,[i],a)
?x:?a:L(m0,pc0,x,a)?L(m0,L0,x,a)
..
.
?x:?a:L(m0,pc0,x,a)?L(m0,L n,x,a)
SECSAFE-IMM-004-1.09
(K,H,L,S)|=CG(m0,pc0):tableswitch t l=>(L i)n1,default=>L0i??y:?i:?a:y=[i+1]∧S(m0,pc0,y,a)?S(m0,L0,[i],a)
..
.
?y:?i:?a:y=[i+1]∧S(m0,pc0,y,a)?S(m0,L n,[i],a)
?x:?a:L(m0,pc0,x,a)?L(m0,L0,x,a)
..
.
?x:?a:L(m0,pc0,x,a)?L(m0,L n,x,a)
Local variables.
(K,H,L,S)|=CG(m0,pc0):load t x i?
?a:L(m0,pc0,var
x,a)
?i:?a:?y:(y=[i+1])∧S(m0,pc0,y,a)?S(m0,pc0+1,[i],a)
?y:?a:(y=var
σ)
?y:?a:?i:y=[i+1]∧S(m0,pc0,[i],a)?S(m0,pc0+1,y,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
(K,H,L,S)|=CG(m0,pc0):getfield f i?
?r:?a:S(m0,pc0,[0],r)∧H(r,f,a)?S(m0,pc0+1,[0],a)
?y:?a:?i:y=[i+1]∧S(m0,pc0,y,a)?S(m0,pc0+1,y,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
(K,H,L,S)|=CG(m0,pc0):getfield this f i?
?r:?a:L(m0,pc0,var
(K,H,L,S)|=CG(m0,pc0):putfield f i?
?r:?a:S(m0,pc0,[1],r)∧S(m0,pc0,[0],a)?H(r,f,a)
?y:?a:?i:y=[i+2]∧S(m0,pc0,y,a)?S(m0,pc0+1,[i],a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
(K,H,L,S)|=CG(m0,pc0):putfield this f i?
?r:?a:L(m0,pc0,var
0,a)
..
.
?a:S(m0,pc0,[|m|?1],a)?L(m,1,var
0,r)
?a:S(m0,pc0,[0],a)?L(m,1,var
|m|,a)
if m.returnType=void then
?y:?a:?i:y=[i+|m|+1]∧S(m0,pc0,y,a)?S(m0,pc0+1,[i],a) if m.returnType=void then
?a:S(m,END m,[0],a)?S(m0,pc0+1,[0],a)
?y:?z:?a:?i:y=[i+|m|+1]∧z=[i+1]∧
S(m0,pc0,y,a)?S(m0,pc0+1,z,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
Note that for de?nite,ie.static and special,methods the end token,END m, need not be looked up,but can be calculated directly since the invoked method is
SECSAFE-IMM-004-1.011
uniquely and completely determined at compile time unlike for virtual methods. (K,H,L,S)|=CG(m0,pc0):invokevirtual m i?
?r:?mv:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)?
L(mv,1,var
1,a)
..
.
?r:?mv:?a:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧
S(m0,pc0,[|m|?1],a)?L(mv,1,var
0,r)
?r:?mv:?a:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧
S(m0,pc0,[0],a)?L(mv,1,var
|m|,a)
if m.returnType=void then
?a:?i:S(m0,pc0,[i+|m|+1],a)?S(m0,pc0+1,|i+1|,a)
?r:?mv:?endmv:?a:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧
END(mv,endmv)∧S(mv,endmv,[0],a)?S(m0,pc0+1,[0],a) if m.returnType=void then
?a:?i:S(m0,pc0,[i+|m|+1],a)?S(m0,pc0+1,|i|,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
When returning from a method,the return value must be copied to the location speci?ed by the end token related to the current method.The end token is computed rather than looked up:
(K,H,L,S)|=CG(m0,pc0):return t i?
,[0],a)
?a:S(m0,pc0,[0],a)?S(m0,END m
As a special case,return without a return value simply generates the always true clause:
(K,H,L,S)|=CG(m0,pc0):return i?
1
Array Support.
(K,H,L,S)|=CG(m0,pc0):new(array t)i?
S(m0,pc0+1,[0],ar
(K,H,L,S)|=CG(m0,pc0):arraylength i?
S(m0,pc0+1,[0],INT)
?y:?a:?i:y=[i+1]∧S(m0,pc0,y,a)?S(m0,pc0+1,y,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
(K,H,L,S)|=CG(m0,pc0):arrayload t i?
?r:?a:S(m0,pc0,[1],r)∧H(r,ARRAY,a)?S(m0,pc0+1,[0],a)
?y:?z:?a:?i:
y=[i+1]∧z=[i+2]∧S(m0,pc0,z,a)?S(m0,pc0+1,y,a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
(K,H,L,S)|=CG(m0,pc0):arraystore t i?
?r:?a:S(m0,pc0,[2],2)∧S(m0,pc0,[0],a)?H(r,ARRAY,a)
?y:?a:?i:
y=[i+3]∧S(m0,pc0,y,a)?S(m0,pc0+1,[i],a)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
5Theoretical Results
In the previous sections we have shown how the Flow Logic speci?cation can be converted into a constraint generating format.In this section we prove that the conversion is correct,in other words:that a solution to the constraints is an acceptable analysis with respect to the Flow Logic speci?cation.
To this end we?rst de?ne a concretisation function on solutions for con-straint systems:
De?nition1Let L,S,K and H be relations de?ned as in Section3.We then de?ne
γ(L)(m,pc)(x)={v|L(m,pc,x,v)}
γ(S)(m,pc)|i={v|S(m,pc,i,v)}
γ(K,H,L,S)=(γ(K),γ(H),γ(L),γ(S))
The above de?nition formalises the intuitive relation between solutions for con-straint systems and analysis estimates.It remains to be shown that this relation does indeed hold;this is stated formally in the following Conjecture:
Fact2
(K,H,L,S)|=CG(m0,pc0):instr i?γ((K,H,L,S))|=(m0,pc0):instr Proof(sketch).The fact is proved by case analysis on instr.
Case(push):We assume that
(K,H,L,S)|=CG(m0,pc0):push v(1) and must prove thatγ((K,H,L,S))|=(m0,pc0):push v.From(1)it follows that
S(m0,pc0+1,[0],INT)(2)
?i:?a:?y:
(y=[i+1])∧S(m0,pc0,[i],a)?S(m0,pc0+1,y,a)(3)
?x:?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)(4) SECSAFE-IMM-004-1.013
From(2)it follows that
γ(S)(m0,pc0+1)|0?{INT}(5) and from(3)we have
?i:?a:a∈γ(S)(m0,pc0)|i?v∈γ(S)(m0,pc0+1)|i+1
which is equivalent to
?i:γ(S)(m0,pc0)|i?γ(S)(m0,pc0+1)|i+1(6) Now combining(5)and(6)yields
{INT}::γ(S)(m0,pc0) γ(S)(m0,pc0+1)(7) From(4)we immediately obtain
?x:
(8)
γ(L)(m0,pc0)(x)?γ(L)(m0,pc0+1)(x)
which is equivalent to
γ(L)(m0,pc0) γ(L)(m0,pc0+1)(9)
6.1.1Parameter Ordering
Earlier versions of the solver were rather sensitive to the particular ordering of parameters in a relation due to the internal representation of relations.Ex-periments(cf.[1])show that choosing the right parameter ordering can have a signi?cant impact on the time needed to solve a particular set of constraints.
To overcome this problem the solver now computes all the relevant reorder-ings of a relation internally,thus allowing it to always choose the best reordering in a given situation.This internal computation is guaranteed to yield the small-est possible number of reorderings needed for binary and tertiary relations.For relations with four or more parameters this cannot be guaranteed.
While the internal computation of all the relevant reorderings can reduce the time needed to solve a set of constraints signi?cantly,it also implies an increase in the space needed to solve the constraints,since a relation may be represented a number of times internally(once for each relevant reordering). For very large constraint sets it may thus be necessary to turn o?the internal computation of reorderings at the price of(possibly)increasing the time needed to solve the constraints.In the long term,the problem can be alleviated by implementing more space e?cient data structures for the internal representation of the di?erent reorderings.
6.1.2Conjunct Ordering in Preconditions
Since the solver evaluates preconditions from left to right by propagating vari-able bindings,called environments,that satisfy subclauses in the precondition, time savings can be achieved by moving subclauses that only allow a small number of environments,ie.subclauses that are only true for a small number of values,more to the left in a precondition,since this reduces the number of environments passed further on in the evaluation of a precondition.
This can be illustrated by looking at the constraints for the invokevirtual instruction.Here the constraints for copying the arguments forward to the invoked method are of the following form:
?r:?mv:?a:
S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧S(m0,pc0,[0],a)?
L(mv,1,var
1,a)
Similarly for the END-tokens(still for the invokevirtual instruction):?r:?mv:?endmv:?a:
S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧END(mv,endmv)∧
S(mv,endmv,[0],a)?S(m0,pc0+1,[0],a)
Here both the ML and the END relations are expected to be quite sparse,thus SECSAFE-IMM-004-1.015
the above should be rewritten as
?r:?mv:?endmv:?a:
END(mv,endmv)∧ML(m.id,r,mv)∧S(m0,pc0,[|m|],r)∧
S(mv,endmv,[0],a)?S(m0,pc0+1,[0],a)
Such optimisations are possible for several instructions.
6.1.3Existential Quanti?cation in Preconditions
Another technique for optimising the time requirement of a set of constraints is to change universal quanti?ers into existential quanti?ers where possible without changing the meaning of a constraint.In general this is possible in the case where a universally quanti?ed variable is used in the precondition but not in the conclusion of an implication,ie.let x be a variable that is not free in pre y and con then a clause of the following form
?x:?y1:···?y n:(pre x∧pre y)?conc
should be converted into
?y1:···?y n:((?x:pre x)∧pre y)?conc
This optimisation is illustrated using the invokevirtual instruction,where the clauses that model the parameter transfer are of the form:
?r:?mv:?a:
S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧S(m0,pc0,[0],a)?
L(mv,1,var
1,a)
6.1.4Sharing Preconditions
It is possible to improve the time and space needed(by a constant factor)by merging clauses with the same preconditions but di?erent conclusions.This then avoids recomputing the precondition for each di?erent conclusion.In symbols, clauses on the form
(pre?conc1)∧(pre?conc2)
are converted into clauses where the shared precondition is made explicit:
pre?(conc1∧conc2)
SECSAFE-IMM-004-1.016
We illustrate this conversion by applying it to the invokevirtual instruction:?r?mv:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)?
L(mv,1,[0],r)
?r?mv?a:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧
S(m0,pc0,[0],a)?L(mv,1,[1],a)
..
.
?r?mv?a:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧
S(m0,pc0,[|m|?1],a)?L(mv,1,[|m|],a)
?a?i:S(m0,pc0,[i+|m|+1],a)?S(m0,pc0+1,|i+1|,a)
?r?mv?endmv?a:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)∧
END(mv,endmv)∧S(mv,endmv,[0],a)?S(m0,pc0+1,[0],a)
?x?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
is converted into
?r?mv:S(m0,pc0,[|m|],r)∧ML(m.id,r,mv)?
L(mv,1,[0],r)
?a:
S(m0,pc0,[0],a)?L(mv,1,[1],a)
..
.
S(m0,pc0,[|m|?1],a)?L(mv,1,[|m|],a)
?endmv:
END(mv,endmv)∧S(mv,endmv,[0],a)?S(m0,pc0+1,[0],a)?a:?i:S(m0,pc0,[i+|m|+1],a)?S(m0,pc0+1,[i+1],a)
?x?a:L(m0,pc0,x,a)?L(m0,pc0+1,x,a)
6.2Path Compression
Rather than“tweaking”the individual clauses,a more global approach could be taken,ie.looking at all the generated clauses.With this approach we can identify paths where information is just copied forward and compress them.For example:
?S(m
,pc0) ?S(m0,pc0+n1) ··· ?S(m0,pc0+n i)
can be compressed to
?S(m
,pc0) ?S(m0,pc0+n i)
and thus eliminating all the intermediate steps.This can be done if and only if all the intermediate variables,ie.?S(m0,pc0+n2),...,?S(m0,pc0+n i?1),have exactly one de?nition and exactly one use.
The clauses that arise from the control?ow analysis are especially likely to have such paths for local variables;most instructions do not access or modify local variables,but the analysis copies them forward nevertheless.Instead of ?nding such paths in the clauses,it would also be possible to lift path compres-sion directly into the?ow logic speci?cation of the control?ow anlaysis by only copying information forward to where it is needed.
SECSAFE-IMM-004-1.017
6.3Better Representation of the Abstract Domains Another approach to reducing space required by the constraints is to?nd better, ie.less space consuming,representations of the abstract domains.The stack and the local heap are obvious candidates for such a representation change,especially in combination with path compression as discussed in Section6.2.
For the stack a possible alternative to the current representation is to use stack variables rather than the full(abstract)stack.The idea is to use place-holders to keep track of the possible stack layouts and then for each placeholder keeping track of the possible values that placeholder can have.The advantage is that it eliminates the need for copying the full set of possible values for a stack position,instead only the placeholder is copied.We are currently work-ing on ideas along these lines,in particular with an eye to using the optimised representation when implementing the data?ow analysis discussed in[3].
7Prototype Implementation
In order to obtain feedback on the analysis and constraint generation as early in the process as possible,a simple constraint generation prototype has been implemented in Haskell(https://www.doczj.com/doc/838667261.html,).We shall not go into any im-plementation details here,but the prototype is available from the author upon request.
The prototype consists of a simple parser,that parses af simpli?ed version of Carmel(called CarmelLight),and a constraint generator for the Succinct Solver.The choice of parsing a simpli?ed Carmel rather than“real”Carmel syntax was made to cut down on the development time of the prototype.
Because of the lack of benchmark programs available in the Carmel syntax, as de?ned in[6],and the absence of an automatic translator from JavaCard to Carmel,a number of simplifying assumptions were made to facilitate the (manual)translation from JavaCard to Carmel.In particular:dynamic method lookup(via the methodLookup function)was replaced by a simpler notion by as-suming that inherited methods are(syntactically)copied to the relevant classes. Furthermore,instead of using the address scheme suggested in[6],based on method and class identities,a simpler addressing scheme is used,based on class and method names instead.The simpler addressing scheme is su?cient when the source code of the entire program being analysed is available.
The above simplifying assumptions only change or in?uence the analysis in minor ways,but they do make it easier and faster to(manually)convert or con-struct benchmark programs that can be used with the prototype implementation of the analysis.
In Section7.2consequences of the above choices are discussed along with suggestions for improvements.
7.1Using the Prototype
In Listing1we give an example of a small CarmelLight program.Note that the#direct{...}command used at the bottom of Listing1is used to send clauses directly to the solver,ie.with no interference from the constraint gen-erator.In this example it is used to encode the maximum stack height;this also ensures that the universe of the solver contains encodings of all the stack SECSAFE-IMM-004-1.018
Listing1:Example program in CarmelLight
positions of relevance.Due to the way the solver is implemented and becuase the stack positions are encoded as nested terms,only the maximum number needs to be speci?ed,the remaining numbers,ie.all subterms of the encoding, are automatically constructed by the solver.
Listing2shows an excerpt of the constraints generated by the prototype im-plementation.The excerpt shows the clauses generated for a method invocation. The full set of constraints generated is shown in Appendix A.1.
Listing3illustrates the output from the solver.The excerpt illustrates the solution for the stack and for the local heap.The full solution is shown in Appendix A.2.
7.2Testing the Prototype
The prototype has been tested on a number of small ad-hoc test programs as well as two Sun JavaCard demo applets:Wallet and JavaPurse(translated from JavaCard to CarmelLight by hand).
The Wallet applet consists of approximately200lines of CarmelLight code while the JavaPurse has around1300lines of CarmelLight code.Both applets make use of various JavaCard API’s;a simpli?ed model of the relevant API calls(taking only rudimentary control?ow into account)were implemented in order to carry out the tests.
Solving the constraints generated for the two test programs took approxi-mately4seconds and22seconds for the Wallet and JavaPurse respectively.An SECSAFE-IMM-004-1.019
Listing2:Excerpt of constraints generated for example program
Listing3:Excerpt of solver output for example program SECSAFE-IMM-004-1.020
有限元网格划分的基本原则 划分网格是建立有限元模型的一个重要环节，它要求考虑的问题较多，需要的工作量较大，所划分的网格形式对计算精度和计算规模将产生直接影响。为建立正确、合理的有限元模型，这里介绍划分网格时应考虑的一些基本原则。 1网格数量 网格数量的多少将影响计算结果的精度和计算规模的大小。一般来讲，网格数量增加，计算精度会有所提高，但同时计算规模也会增加，所以在确定网格数量时应权衡两个因数综合考虑。 图1中的曲线1表示结构中的位移随网格数量收敛的一般曲线，曲线2代表计算时间随网格数量的变化。可以看出，网格较少时增加网格数量可以使计算精度明显提高，而计算时间不会有大的增加。当网格数量增加到一定程度后，再继续增加网格时精度提高甚微，而计算时间却有大幅度增加。所以应注意增加网格的经济性。实际应用时可以比较两种网格划分的计算结果，如果两次计算结果相差较大，可以继续增加网格，相反则停止计算。 图1位移精度和计算时间随网格数量的变化 在决定网格数量时应考虑分析数据的类型。在静力分析时，如果仅仅是计算结构的变形，网格数量可以少一些。如果需要计算应力，则在精度要求相同的情况下应取相对较多的网格。同样在响应计算中，计算应力响应所取的网格数应比计算位移响应多。在计算结构固有动力特性时，若仅仅是计算少数低阶模态，可以选择较少的网格，如果计算的模态阶次较高，则应选择较多的网格。在热分析中，结构内部的温度梯度不大，不需要大量的内部单元，这时可划分较少的网格。 2网格疏密 网格疏密是指在结构不同部位采用大小不同的网格，这是为了适应计算数据的分布特点。在计算数据变化梯度较大的部位(如应力集中处)，为了较好地反映数据变化规律，需要采用比较密集的网格。而在计算数据变化梯度较小的部位，为减小模型规模，则应划分相对稀疏的网格。这样，整个结构便表现出疏密不同的网格划分形式。 图2是中心带圆孔方板的四分之一模型，其网格反映了疏密不同的划分原则。小圆孔附近存在应力集中，采用了比较密的网格。板的四周应力梯度较小，网格分得较稀。其中图b中网格疏密相差更大，它比图a中的网格少48个，但计算出的孔缘最大应力相差1%，而计算时间却减小了36%。由此可见，采用疏密不同的网格划分，既可以保持相当的计算精度，又可使网格数量减小。因此，网格数量应增加到结构的关键部位，在次要部位增加网格是不必要的，也是不经济的。
文章编号:1003-0794(2005)01-0038-02 基于ANSYS的有限元法网格划分浅析 杨小兰,刘极峰,陈 旋 (南京工程学院,南京210013) 摘要:为提高有限元数值的计算精度和对复杂结构力学分析的准确性,针对不同分析类型采用了不同的网格划分方法,结合实例阐述了ANSYS有限元网格划分的方法和技巧,指出了采用ANSYS有限元软件在网格划分时应注意的技术问题。 关键词:ANSYS;有限元;网格;计算精度 中图号:O241 82;TP391 7文献标识码:A 1 引言 ANSYS有限元分析程序是著名的C AE供应商美国ANSYS公司的产品,主要用于结构、热、流体和电磁四大物理场独立或耦合分析的CAE应用,功能强大,应用广泛,是一个便于学习和使用的优秀有限元分析程序。在ANSYS得到广泛应用的同时,许多技术人员对ANSYS程序的了解和认识还不够系统全面,在工作和研究中存在许多隐患和障碍,尤为突出的是有限元网格划分技术。本文结合工程实例,就如何合理地进行网格划分作一浅析。 2 网格划分对有限元法求解的影响 有限元法的基本思想是把复杂的形体拆分为若干个形状简单的单元,利用单元节点变量对单元内部变量进行插值来实现对总体结构的分析,将连续体进行离散化即称网格划分,离散而成的有限元集合将替代原来的弹性连续体,所有的计算分析都将在这个模型上进行。因此,网格划分将关系到有限元分析的规模、速度和精度以及计算的成败。实验表明:随着网格数量的增加,计算精确度逐渐提高,计算时间增加不多;但当网格数量增加到一定程度后,再继续增加网格数量,计算精确度提高甚微,而计算时间却大大增加。在进行网格划分时,应注意网格划分的有效性和合理性。 3 网格划分的有效性和合理性 (1)根据分析数据的类型选择合理的网格划分数量 在决定网格数量时应考虑分析数据的类型。在静力分析时,如果仅仅是计算结构的变形,网格数量可以少一些。如果需要计算应力,则在精度要求相同的情况下取相对较多的网格。同样在响应计算中,计算应力响应所取的网格数应比计算位移响应多。在计算结构固有动力特性时,若仅仅是计算少数低阶模态,可以选择较少的网格。如果计算的模态阶次较高,则应选择较多的网格。在热分析中,结构内部的温度梯度不大,不需要大量的内部单元,可划分较少的网格。 (2)根据分析数据的分布特点选择合理的网格疏密度 在决定网格疏密度时应考虑计算数据的分布特点,在计算固有特性时,因为固有频率和振型主要取决于结构质量分布和刚度分布,采用均匀网格可使结构刚度矩阵和质量矩阵的元素不致相差很大,可减小数值计算误差。同样,在结构温度场计算中也趋于采用均匀的网格形式。在计算数据变化梯度较大的部位时,为了更好地反映数据变化规律,需要采用比较密集的网格,而在计算数据变化梯度较小的部位,为了减小模型规模,则应划分相对稀疏的网格,这样整个结构就表现出疏密不同的网格划分形式。 以齿轮轮齿的有限元分析模型为例,由于分析的目的是求出齿轮啮合传动过程中齿根部分的弯曲应力,因此,分析计算时并不需要对整个齿轮进行计算,可根据圣文男原理将整个区域缩小到直接参与啮合的轮齿。虽然实际上参与啮合的齿数总大于1,但考虑到真正起作用的是单齿,通常只取一个轮齿作为分析对象,这样作可以大大节省计算机内存。考虑到轮齿应力在齿根过渡圆角和靠近齿面处变化较大,网格可划分得密一些。在进行疏密不同网格划分操作时可采用ANSYS提供的网格细化工具调整网格的疏密,也可采用分块建模法设置网格疏密度。 图1所示即为采用分块建模法进行网格划分。图1(a)为内燃机中重要运动零件连杆的有限元应力分析图,由于连杆结构对称于其摆动的中间平面,其厚度方向的尺寸远小于长度方向的尺寸,且载荷沿厚度方向近似均匀分布,故可按平面应力分析处 38 煤 矿 机 械 2005年第1期
CATIA有限元高级网格划分教程 盛选禹李明志 1.1进入高级网格划分工作台 （1）打开例题中的文件Sample01.CATPart。 （2）点击主菜单中的【开始】→【分析与模拟】→【Advanced Meshing Tools】(高级网格划分工具），就进入【Advanced Meshing Tools】（高级网格划分工具）工作台，如图1－1所示。进入工作台后，生成一个新的分析文件，并且显示一个【New Analysis Case】（新分析算题）对话框，如图1－2所示。 图1－1【开始】→【分析与模拟】→【Advanced Meshing Tools】(高级网格划分工具）（3）在【New Analysis Case】（新分析算题）对话框内选择【Static Analysis】（静力分析）选项。如果以后打开该对话框的时候均希望是计算静力分析，可以把对话框内的【Keep as default starting analysis case】（在开始时保持为默认选项）勾选。这样，下次进入本工作台时，将自动选择静力分析。 （4）点击【新分析算题】对话框内的【确定】按钮，关闭对话框。 1.2定义曲面网格划分参数 本节说明如何定义一个曲面零件的网格类型和全局参数。 （1）点击【Meshing Method】(网格划分方法)工具栏内的【高级曲面划分】按钮
，如图1－3所示。需要在【Meshing Method】(网格划分方法)工具栏内点击中间按钮的下拉箭头才能够显示出【高级曲 面划分】按钮。 图1－2【New Analysis Case】（新分析算题）对话框图1－3【高级曲面划分】按钮
有限元网格划分 摘要:总结近十年有限元网格划分技术发展状况。首先,研究和分析有限元网格划分的基本原则；其次,对当前典型网格划分方法进行科学地分类,结合实例,系统地分析各种网格划分方法的机理、特点及其适用范围,如映射法、基于栅格法、节点连元法、拓扑分解法、几何分解法和扫描法等；再次,阐述当前网格划分的研究热点,综述六面体网格和曲面网格划分技术；最后,展望有限元网格划分的发展趋势。 关键词:有限元网格划分；映射法；节点连元法;拓扑分解法；几何分解法；扫描法；六面体网格 1 引言 有限元网格划分是进行有限元数值模拟分析至关重要的一步，它直接影响着后续数值计算分析结果的精确性。网格划分涉及单元的形状及其拓扑类型、单元类型、网格生成器的选择、网格的密度、单元的编号以及几何体素。在有限元数值求解中，单元的等效节点力、刚度矩阵、质量矩阵等均用数值积分生成，连续体单元以及壳、板、梁单元的面内均采用高斯（Gauss）积分，而壳、板、梁单元的厚度方向采用辛普生（Simpson）积分。 2 有限元网格划分的基本原则 有限元方法的基本思想是将结构离散化,即对连续体进行离散化,利用简化几何单元来近似逼近连续体,然后根据变形协调条件综合求解。所以有限元网格的划分一方面要考虑对各物体几何形状的准确描述,另一方面也要考虑变形梯度的准确描述。为正确、合理地建立有限元模型,这里介绍划分网格时应考虑的一些基本原则。 2.1 网格数量 网格数量直接影响计算精度和计算时耗,网格数量增加会提高计
算精度,但同时计算时耗也会增加。当网格数量较少时增加网格，计算精度可明显提高,但计算时耗不会有明显增加;当网格数量增加到一定程度后,再继续增加网格时精度提高就很小,而计算时耗却大幅度增加。所以在确定网格数量时应权衡这两个因素综合考虑。 2.2 网格密度 为了适应应力等计算数据的分布特点,在结构不同部位需要采用大小不同的网格。在孔的附近有集中应力,因此网格需要加密;周边应力梯度相对较小,网格划分较稀。由此反映了疏密不同的网格划分原则:在计算数据变化梯度较大的部位,为了较好地反映数据变化规律,需要采用比较密集的网格;而在计算数据变化梯度较小的部位,为减小模型规模,网格则应相对稀疏。 2.3 单元阶次 单元阶次与有限元的计算精度有着密切的关联,单元一般具有线性、二次和三次等形式,其中二次和三次形式的单元称为高阶单元。高阶单元的曲线或曲面边界能够更好地逼近结构的曲线和曲面边界,且高次插值函数可更高精度地逼近复杂场函数,所以增加单元阶次可提高计算精度。但增加单元阶次的同时网格的节点数也会随之增加,在网格数量相同的情况下由高阶单元组成的模型规模相对较大,因此在使用时应权衡考虑计算精度和时耗。 2.4 单元形状 网格单元形状的好坏对计算精度有着很大的影响,单元形状太差的网格甚至会中止计算。单元形状评价一般有以下几个指标: (1)单元的边长比、面积比或体积比以正三角形、正四面体、正六面体为参考基准。 (2)扭曲度:单元面内的扭转和面外的翘曲程度。 (3)节点编号:节点编号对于求解过程中总刚矩阵的带宽和波前因数有较大的影响,从而影响计算时耗和存储容量的大小 2.5 单元协调性 单元协调是指单元上的力和力矩能够通过节点传递给相邻单元。为保证单元协调,必须满足的条件是: (1)一个单元的节点必须同时也是相邻点,而不应是内点或边界
一、基本有限元网格概念 1．单元概述?几何体划分网格之前需要确定单元类型.单元类型的选择应该根据分析类型、形状特征、计算数据特点、精度要求和计算的硬件条件等因素综合考虑。为适应特殊的分析对象和边界条件,一些问题需要采用多种单元进行组合建模。? 2.单元分类选择单元首先需要明确单元的类型，在结构有限元分析中主要有以下一些单元类型：平面应力单元、平面应变单元、轴对称实体单元、空间实体单元、板单元、壳单元、轴对称壳单元、杆单元、梁单元、弹簧单元、间隙单元、质量单元、摩擦单元、刚体单元和约束单元等。根据不同的分类方法,上述单元可以分成以下不同的形式。?3。按照维度进行单元分类 根据单元的维数特征，单元可以分为一维单元、二维单元和三维单元。?一维单元的网格为一条直线或者曲线。直线表示由两个节点确定的线性单元。曲线代表由两个以上的节点确定的高次单元,或者由具有确定形状的线性单元。杆单元、梁单元和轴对称壳单元属于一维单元,如图1~图3所示。 ?二维单元的网 格是一个平面或者曲面，它没有厚度方向的尺寸.这类单元包括平面单元、轴对称实体单元、板单元、壳单元和复合材料壳单元等,如图4所示。二维单元的形状通常具有三角形和四边形两种，在使用自动网格剖分时,这类单元要求的几何形状是表面模型或者实体模型的边界面。采用薄壳单元通常具有相当好的计算效率。
??三维单元的网格具有空间三个方向的尺寸，其形状具有四面体、五面体和六面体,这类单元包括空间实体单元和厚壳单元，如图5所示．在自动网格划分时，它要求的是几何模型是实体模型(厚壳单元是曲面也可以）。 ? 4.按照插值函数进行单元分类 根据单元插值函数多项式的最高阶数多少，单元可以分为线性单元、二次单元、三次单元和更高次的单元。 线性单元具有线性形式的插值函数,其网格通常只具有角节点而无边节点，网格边界为直线或者平面.这类单元的优点是节点数量少，在精度要求不高或者结果数据梯度不太大的情况下，采用线性单元可以得到较小的模型规模.但是由于单元位移函数是线性的，单元内的位移呈线性变化,而应力是常数,因此会造成单元间的应力不连续,单元边界上存在着应力突变，如图6所示。
题目：请比较PageRank算法和HITS算法的优缺点，除此之外，请再介绍2种用于搜索引擎检索结果的排序算法，并举例说明。 答： 1998年，Sergey Brin和Lawrence Page[1]提出了PageRank算法。该算法基于“从许多优质的网页链接过来的网页，必定还是优质网页”的回归关系，来判定网页的重要性。该算法认为从网页A导向网页B的链接可以看作是页面A对页面B的支持投票，根据这个投票数来判断页面的重要性。当然，不仅仅只看投票数，还要对投票的页面进行重要性分析，越是重要的页面所投票的评价也就越高。根据这样的分析，得到了高评价的重要页面会被给予较高的PageRank值，在检索结果内的名次也会提高。PageRank是基于对“使用复杂的算法而得到的链接构造”的分析，从而得出的各网页本身的特性。 HITS 算法是由康奈尔大学( Cornell University ) 的JonKleinberg 博士于1998 年首先提出。Kleinberg认为既然搜索是开始于用户的检索提问，那么每个页面的重要性也就依赖于用户的检索提问。他将用户检索提问分为如下三种：特指主题检索提问（specific queries，也称窄主题检索提问）、泛指主题检索提问（Broad-topic queries，也称宽主题检索提问）和相似网页检索提问（Similar-page queries）。HITS 算法专注于改善泛指主题检索的结果。 Kleinberg将网页（或网站）分为两类，即hubs和authorities，而且每个页面也有两个级别，即hubs（中心级别）和authorities（权威级别）。Authorities 是具有较高价值的网页，依赖于指向它的页面；hubs为指向较多authorities的网页，依赖于它指向的页面。HITS算法的目标就是通过迭代计算得到针对某个检索提问的排名最高的authority的网页。 通常HITS算法是作用在一定范围的，例如一个以程序开发为主题的网页，指向另一个以程序开发为主题的网页，则另一个网页的重要性就可能比较高，但是指向另一个购物类的网页则不一定。在限定范围之后根据网页的出度和入度建立一个矩阵，通过矩阵的迭代运算和定义收敛的阈值不断对两个向量authority 和hub值进行更新直至收敛。 从上面的分析可见，PageRank算法和HITS算法都是基于链接分析的搜索引擎排序算法，并且在算法中两者都利用了特征向量作为理论基础和收敛性依据。
ANSYS有限元网格划分的基本要点 1引言 ANSYS有限元网格划分是进行数值模拟分析至关重要的一步，它直接影响着后续数值计算分析结果的精确性。网格划分涉及单元的形状及其拓扑类型、单元类型、网格生成器的选择、网格的密度、单元的编号以及几何体素。从几何表达上讲，梁和杆是相同的，从物理和数值求解上讲则是有区别的。同理，平面应力和平面应变情况设计的单元求解方程也不相同。在有限元数值求解中，单元的等效节点力、刚度矩阵、质量矩阵等均用数值积分生成，连续体单元以及壳、板、梁单元的面内均采用高斯（Gauss）积分，而壳、板、梁单元的厚度方向采用辛普生（Simpson）积分。辛普生积分点的间隔是一定的，沿厚度分成奇数积分点。由于不同单元的刚度矩阵不同，采用数值积分的求解方式不同，因此实际应用中，一定要采用合理的单元来模拟求解。 2ANSYS网格划分的指导思想 ANSYS网格划分的指导思想是首先进行总体模型规划，包括物理模型的构造、单元类型的选择、网格密度的确定等多方面的内容。在网格划分和初步求解时，做到先简单后复杂，先粗后精，2D单元和3D单元合理搭配使用。为提高求解的效率要充分利用重复与对称等特征，由于工程结构一般具有重复对称或轴对称、镜象对称等特点，采用子结构或对称模型可以提高求解的效率和精度。利用轴对称或子结构时要注意场合，如在进行模态分析、屈曲分析整体求解时，则应采用整体模型，同时选择合理的起点并设置合理的坐标系，可以提高求解的精度和效率，例如，轴对称场合多采用柱坐标系。有限元分析的精度和效率与单元的密度和几何形状有着密切的关系，按照相应的误差准则和网格疏密程度，避免网格的畸形。在网格重划分过程中常采用曲率控制、单元尺寸与数量控制、穿透控制等控制准则。在选用单元时要注意剪力自锁、沙漏和网格扭曲、不可压缩材料的体积自锁等问题 ANSYS软件平台提供了网格映射划分和自由适应划分的策略。映射划分用于曲线、曲面、实体的网格划分方法，可使用三角形、四边形、四面体、五面体和六面体，通过指定单元边长、网格数量等参数对网格进行严格控制，映射划分只用于规则的几何图素，对于裁剪曲面或者空间自由曲面等复杂几何体则难以
ANSYS有限元分析中的网格划分 有限元分析中的网格划分好坏直接关系到模型计算的准确性。本文简述了网格划分应用的基本理论，并以ANSYS限元分析中的网格划分为实例对象，详细讲述了网格划分基本理论及其在工程中的实际应用，具有一定的指导意义。 作者: 张洪才 关键字: CAE ANSYS 网格划分有限元 1 引言 ANSYS有限元网格划分是进行数值模拟分析至关重要的一步，它直接影响着后续数值计算分析结果的精确性。网格划分涉及单元的形状及其拓扑类型、单元类型、网格生成器的选择、网格的密度、单元的编号以及几何体素。从几何表达上讲，梁和杆是相同的，从物理和数值求解上讲则是有区别的。同理，平面应力和平面应变情况设计的单元求解方程也不相同。在有限元数值求解中，单元的等效节点力、刚度矩阵、质量矩阵等均用数值积分生成，连续体单元以及壳、板、梁单元的面内均采用高斯（Gauss）积分，而壳、板、梁单元的厚度方向采用辛普生（Simpson）积分。辛普生积分点的间隔是一定的，沿厚度分成奇数积分点。由于不同单元的刚度矩阵不同，采用数值积分的求解方式不同，因此实际应用中，一定要采用合理的单元来模拟求解。 2 ANSYS网格划分的指导思想 ANSYS网格划分的指导思想是首先进行总体模型规划，包括物理模型的构造、单元类型的选择、网格密度的确定等多方面的内容。在网格划分和初步求解时，做到先简单后复杂，先粗后精，2D单元和3D单元合理搭配使用。为提高求解的效率要充分利用重复与对称等特征，由于工程结构一般具有重复对称或轴对称、镜象对称等特点，采用子结构或对称模型可以提高求解的效率和精度。利用轴对称或子结构时要注意场合，如在进行模态分析、屈曲分析整体求解时，则应采用整体模型，同时选择合理的起点并设置合理的坐标系，可以提高求解的精度和效率，例如，轴对称场合多采用柱坐标系。有限元分析的精度和效率与单元的密度和几何形状有着密切的关系，按照相应的误差准则和网格疏密程度，避免网格的畸形。在网格重划分过程中常采用曲率控制、单元尺寸与数量控制、穿透控制等控制准则。在选用单元时要注意剪力自锁、沙漏和网格扭曲、不可压缩材料的体积自锁等问题ANSYS软件平台提供了网格映射划分和自由适应划分的策略。映射划分用于曲线、曲面、实体的网格划分方法，可使用三角形、四边形、四面体、五面体和六面体，通过指定单元边长、网格数量等参数对网格进行严格控制，映射划分只用于规则的几何图素，对于裁剪曲面或者空间自由曲面等复杂几何体则难以控制。自由网格划分用于空间自由曲面和复杂实体，采用三角形、四边形、四面体进行划分，采用网格数量、边长及曲率来控制网格的质量。 3 ANSYS网格划分基本原则 3.1 网格数量 网格数量的多少将影响计算结果的精度和计算规模的大小。一般来讲，网格数量增加，计算精度会有所提高，但同时计算规模也会增加，所以在确定网格数量时应权衡两个因数综合考虑。 图1 位移精度和计算时间随网格数量的变化 图1中的曲线1表示结构中的位移随网格数量收敛的一般曲线，曲线2代表计算时间随
结构有限元分析中的网格划分技术及其应用实例 结构有限元分析中的网格划分是否直接关系到解算的效果。本文简述了网格划分应用的基本理论，并以空间自由曲面覆盖件和大型整体网络钢筋壳体产品的有限元分析中的网格划分为实例对象，详细讲述了空间自由和三维实体的网格划分基本理论及其在工程中的实际应用，非常具有现实意义和借鉴价值。 一、前言 有限元网格划分是进行有限元数值模拟分析至关重要的一步，它直接影响着后续数值计算分析结果的精确性。网格划分涉及单元的形状及其拓扑类型、单元类型、网格生成器的选择、网格的密度、单元的编号以及几何体素。从几何表达上讲，梁和杆是相同的，从物理和数值求解上讲则是有区别的。同理，平面应力和平面应变情况设计的单元求解方程也不相同。在有限元数值求解中，单元的等效节点力、刚度矩阵、质量矩阵等均用数值积分生成，连续体单元以及壳、板、梁单元的面内均采用高斯（Gauss）积分，而壳、板、梁单元的厚度方向采用辛普生（Simpson）积分。辛普生积分点的间隔是一定的，沿厚度分成奇数积分点。由于不同单元的刚度矩阵不同，采用数值积分的求解方式不同，因此实际应用中，一定要采用合理的单元来模拟求解。 CAD软件中流行的实体建模包括基于特征的参数化建模和空间自由曲面混合造型两种 方法。Pro/E和SoildWorks是特征参数化造型的代表，而 CATIA与Unigraphics等则将特征参数化和空间自由曲面混合造型有机的结合起来。现有CAD软件对表面形态的表示法已经大大超过了CAE软件，因此，在将CAD实体模型导入CAE软件的过程中，必须将CAD模型中其他表示法的表面形态转换到CAE软件的表示法上，转换精度的高低取决于接口程序的好坏。在转换过程中，程序需要解决好几何图形（曲线与曲面的空间位置）和拓扑关系（各图形数据的逻辑关系）两个关键问题。其中几何图形的传递相对容易实现，而图形间的拓扑关系容易出现传递失败的情况。数据传递面临的一个重大挑战是，将导入CAE程序的CAD模型改造成适合有限元分析的网格模型。在很多情况下，导入CAE程序的模型可能包含许多设计细节，如细小的孔、狭窄的槽，甚至是建模过程中形成的小曲面等。这些细节往往不是基于结构的考虑，保留这些细节，单元数量势必增加，甚至会掩盖问题的主要矛盾，对分析结果造成负面影响。 CAD模型的“完整性”问题是困扰网格剖分的障碍之一。对于同一接口程序，数据传递的品质取决于CAD模型的精度。部分CAD模型对制造检测来说具备足够的精度，但对有限元网格剖分来说却不能满足要求。值得庆幸的是，这种问题通常可通过CAD软件的“完整性检查”来修正。改造模型可取的办法是回到CAD系统中按照分析的要求修改模型。一方面检查模型的完整性，另一方面剔除对分析无用的细节特征。但在很多情况下，这种“回归”很难实现，模型的改造只有依靠 CAE软件自身。CAE中最直接的办法是依靠软件具有的“重构”功能，即剔除细部特征、缝补面和将小面“融入”大曲面等。有些专用接口在模型传递过程中甚至允许自动完成这种工作，并且通过网格剖分器检验模型的“完整性”，如发现“完整性”不能满足要求，接口程序可自动进行“完整性”修复。当几何模型距 CAE分析的要求相差太大时，还可利用CAE程序的造型功能修正几何模型。“布尔运算”是切除细节和修理非完整特征的有效工具之一。 目前数据传递一般可通过专用数据接口，CAE程序可与CAD程序“交流”后生成与CAE 程序兼容的数据格式。另一种方式是通过标准图形格式如IGES、 SAT和ParaSolid传递。现有的CAD平台与通用有限元平台一般通过IGES、STL、Step、Parasolid等格式来数据交
A N S Y S有限元网格划 分的基本原则
ANSYS有限元网格划分的基本原则 发表时间：2009-4-3 作者: 张洪才 关键字: CAE ANSYS 网格划分有限元 有限元分析中的网格划分好坏直接关系到模型计算的准确性。本文简述了网格划分应用的基本理论，并以ANSYS限元分析中的网格划分为实例对象，详细讲述了网格划分基本理论及其在工程中的实际应用，具有一定的指导意义。 1 引言 ANSYS有限元网格划分是进行数值模拟分析至关重要的一步，它直接影响着后续数值计算分析结果的精确性。网格划分涉及单元的形状及其拓扑类型、单元类型、网格生成器的选择、网格的密度、单元的编号以及几何体素。 从几何表达上讲，梁和杆是相同的，从物理和数值求解上讲则是有区别的。同理，平面应力和平面应变情况设计的单元求解方程也不相同。 在有限元数值求解中，单元的等效节点力、刚度矩阵、质量矩阵等均用数值积分生成，连续体单元以及壳、板、梁单元的面内均采用高斯（Gauss）积分，而壳、板、梁单元的厚度方向采用辛普生（Simpson）积分。辛普生积分点的间隔是一定的，沿厚度分成奇数积分点。由于不同单元的刚度矩阵不同，采用数值积分的求解方式不同，因此实际应用中，一定要采用合理的单元来模拟求解。 2 ANSYS网格划分的指导思想 ANSYS网格划分的指导思想是首先进行总体模型规划，包括物理模型的构造、单元类型的选择、网格密度的确定等多方面的内容。 在网格划分和初步求解时，做到先简单后复杂，先粗后精，2D单元和3D 单元合理搭配使用。为提高求解的效率要充分利用重复与对称等特征，由于工程结构一般具有重复对称或轴对称、镜象对称等特点，采用子结构或对称模型可以提高求解的效率和精度。利用轴对称或子结构时要注意场合，如在进行模态分析、屈曲分析整体求解时，则应采用整体模型，同时选择合理的起点并设置合理的坐标系，可以提高求解的精度和效率，例如，轴对称场合多采用柱坐标系。有限元分析的精度和效率与单元的密度和几何形状有着密切的关系，按照相应的误差准则和网格疏密程度，避免网格的畸形。在网格重划分过程中常采用曲率控制、单元尺寸与数量控制、穿透控制等控制准则。在选用单元时要注意剪力自锁、沙漏和网格扭曲、不可压缩材料的体积自锁等问题 ANSYS软件平台提供了网格映射划分和自由适应划分的策略。映射划分用于曲线、曲面、实体的网格划分方法，可使用三角形、四边形、四面体、五面体和六面体，通过指定单元边长、网格数量等参数对网格进行严格控制，映射划分只用于规则的几何图素，对于裁剪曲面或者空间自由曲面等复杂几何体则难以控制。自由网格划分用于空间自由曲面和复杂实体，采用三角形、四边形、四面体进行划分，采用网格数量、边长及曲率来控制网格的质量。
本文讨论了有限元网格的重要概念，包括单元的分类、有限元误差的分类与影响因素;并讨论分析结果的收敛性控制方法，并由实例说明了网格质量及收敛性对取得准确分析结果的重要性。同时讨论了一些重要网格控制的建议及其他网格设定的说明。 一、基本有限元网格概念 1.单元概述 几何体划分网格之前需要确定单元类型。单元类型的选择应该根据分析类型、形状特征、计算数据特点、精度要求和计算的硬件条件等因素综合考虑。为适应特殊的分析对象和边界条件，一些问题需要采用多种单元进行组合建模。 2.单元分类 选择单元首先需要明确单元的类型，在结构有限元分析中主要有以下一些单元类型：平面应力单元、平面应变单元、轴对称实体单元、空间实体单元、板单元、壳单元、轴对称壳单元、杆单元、梁单元、弹簧单元、间隙单元、质量单元、摩擦单元、刚体单元和约束单元等。根据不同的分类方法，上述单元可以分成以下不同的形式。 3.按照维度进行单元分类 根据单元的维数特征，单元可以分为一维单元、二维单元和三维单元。 一维单元的网格为一条直线或者曲线。直线表示由两个节点确定的线性单元。曲线代表由两个以上的节点确定的高次单元，或者由具有确定形状的线性单元。杆单元、梁单元和轴对称壳单元属于一维单元，如图1～图3所示。
二维单元的网格是一个平面或者曲面，它没有厚度方向的尺寸。这类单元包括平面单元、轴对称实体单元、板单元、壳单元和复合材料壳单元等，如图4所示。二维单元的形状通常具有三角形和四边形两种，在使用自动网格剖分时，这类单元要求的几何形状是表面模型或者实体模型的边界面。采用薄壳单元通常具有相当好的计算效率。 三维单元的网格具有空间三个方向的尺寸，其形状具有四面体、五面体和六面体，这类单元包括空间实体单元和厚壳单元，如图5所示。在自动网格划分时，它要求的是几何模型是实体模型(厚壳单元是曲面也可以)。 4.按照插值函数进行单元分类 根据单元插值函数多项式的最高阶数多少，单元可以分为线性单元、二次单元、三次单元和更高次的单元。 线性单元具有线性形式的插值函数，其网格通常只具有角节点而无边节点，网格边界为直线或者平面。这类单元的优点是节点数量少，在精度要求不高或
一、基本有限元网格概念 1.单元概述 几何体划分网格之前需要确定单元类型。单元类型的选择应该根据分析类型、形状特征、计算数据特点、精度要求和计算的硬件条件等因素综合考虑。为适应特殊的分析对象和边界条件，一些问题需要采用多种单元进行组合建模。 2.单元分类 选择单元首先需要明确单元的类型，在结构有限元分析中主要有以下一些单元类型：平面应力单元、平面应变单元、轴对称实体单元、空间实体单元、板单元、壳单元、轴对称壳单元、杆单元、梁单元、弹簧单元、间隙单元、质量单元、摩擦单元、刚体单元和约束单元等。根据不同的分类方法，上述单元可以分成以下不同的形式。 3.按照维度进行单元分类 根据单元的维数特征，单元可以分为一维单元、二维单元和三维单元。 一维单元的网格为一条直线或者曲线。直线表示由两个节点确定的线性单元。曲线代表由两个以上的节点确定的高次单元，或者由具有确定形状的线性单元。杆单元、梁单元和轴对称壳单元属于一维单元，如图1～图3所示。 二维单元的网格是一个平面或者曲面，它没有厚度方向的尺寸。这类单元包括平面单元、轴对称实体单元、板单元、壳单元和复合材料壳单元等，如图4所示。二维单元的形状通常具有三角形和四边形两种，在使用自动网格剖分时，这类单元要求的几何形状是表面模型或者实体模型的边界面。采用薄壳单元通常具有相当好的计算效率。
三维单元的网格具有空间三个方向的尺寸，其形状具有四面体、五面体和六面体，这类单元包括空间实体单元和厚壳单元，如图5所示。在自动网格划分时，它要求的是几何模型是实体模型(厚壳单元是曲面也可以)。 4.按照插值函数进行单元分类 根据单元插值函数多项式的最高阶数多少，单元可以分为线性单元、二次单元、三次单元和更高次的单元。 线性单元具有线性形式的插值函数，其网格通常只具有角节点而无边节点，网格边界为直线或者平面。这类单元的优点是节点数量少，在精度要求不高或者结果数据梯度不太大的情况下，采用线性单元可以得到较小的模型规模。但是由于单元位移函数是线性的，单元内的位移呈线性变化，而应力是常数，因此会造成单元间的应力不连续，单元边界上存在着应力突变，如图6所示。
PageRank算法实验报告 一、算法介绍 PageRank是Google专有的算法，用于衡量特定网页相对于搜索引擎索引中的其他网页而言的重要程度。它由Larry Page 和Sergey Brin在20世纪90年代后期发明。PageRank实现了将链接价值概念作为排名因素。 PageRank的核心思想有2点： 1.如果一个网页被很多其他网页链接到的话说明这个网页比较重要，也就是pagerank值会相对较高； 2.如果一个pagerank值很高的网页链接到一个其他的网页，那么被链接到的网页的pagerank值会相应地因此而提高。 若页面表示有向图的顶点，有向边表示链接，w(i,j)=1表示页面i存在指向页面j的超链接，否则w(i,j)=0。如果页面A存在指向其他页面的超链接，就将A 的PageRank的份额平均地分给其所指向的所有页面，一次类推。虽然PageRank 会一直传递，但总的来说PageRank的计算是收敛的。 实际应用中可以采用幂法来计算PageRank，假如总共有m个页面，计算如公式所示： r=A*x 其中A=d*P+（1-d)*(e*e'/m) r表示当前迭代后的PageRank，它是一个m行的列向量,x是所有页面的PageRank初始值。 P由有向图的邻接矩阵变化而来，P'为邻接矩阵的每个元素除以每行元素之和得到。 e是m行的元素都为1的列向量。 二、算法代码实现
三、心得体会 在完成算法的过程中，我有以下几点体会： 1、在动手实现的过程中，先将算法的思想和思路理解清楚，对于后续动手实现 有很大帮助。 2、在实现之前，对于每步要做什么要有概念，然后对于不会实现的部分代码先 查找相应的用法，在进行整体编写。 3、在实现算法后，在寻找数据验证算法的过程中比较困难。作为初学者，对于 数据量大的数据的处理存在难度，但数据量的数据很难寻找，所以难以进行实例分析。
一个典型的ANSYS分析过程可分为以下6个步骤： 1定义参数 2创建几何模型 3划分网格 4加载数据 5求解 6结果分析 1定义参数 1.1指定工程名和分析标题 启动ANSYS软件，选择File→Change Jobname命令 选择File→Change Title菜单命令 1.2定义单位 (2) 设置计算类型 ANSYS Main Menu: Preference→Material Props →Material Models →Structural →OK (3) 定义分析类型 ANSYS Main Menu: Preprocessor →Loads →Analysis Type →New Analysis→STATIC →OK 1.3定义单元类型 选择Main Menu→Preprocessor→Element Type→Add/Edit/Delete命令 单击[Options]按钮，在[Element behavior]下拉列表中选择[Plane strs w/thk]选项，单击确定 1.4定义单元常数 在ANSYS程序主界面中选择Main Menu→Preprocessor→Real Constants→Add/Edit/Delete命令 单击[Add]按钮，进行下一个[Choose Element Type]对话框 1.5定义材料参数 在ANSYS程序主界面，选择Main Menu→Preprocessor→Material Props→Material Models命令 (1)选择对话框右侧Structural→Linear→Elastic→Isotropic命令，并单击[Isotropic]选项，接着弹出如下所示[Linear Isotropic Properties for Material Number 1]对话框。 在[EX]文本框中输入弹性模量“200000”，在[PRXY]文本框中输入泊松比“0.3”，单击OK 2创建几何模型 在ANSYS程序主界面，选择Main Menu→Preprocessor→Modeling→Creat→Areas→Rectangle →By 2Corners命令 选择Main Menu→Preprocessor→Modeling→Creat→Areas→Circle→Solid Circle命令 3网格划分(之前一定要进行材料的定义和分配) 选择Main Menu→Preprocessor→Modeling→Operate→Booleans→Subtract→Arears Circle命令 选择Main Menu→Preprocessor→Meshing→Mesh→Areas→Free命令，弹出实体选择对话框，单击[Pick All]按钮，得到如下所示网格 4加载数据 (1)选择Main Menu→Preprocessor→Loads→Define Loads→Apply→Structural→Displacement→On Lines命令， 出现如下所示对话框，选择约束[ALL DOF]选项，并设置[Displacement value]为0，单击OK。
如何理解网页和网页之间的关系，特别是怎么从这些关系中提取网页中除文字以外的其他特性。这部分的一些核心算法曾是提高搜索引擎质量的重要推进力量。另外，我们这周要分享的算法也适用于其他能够把信息用结点与结点关系来表达的信息网络。 今天，我们先看一看用图来表达网页与网页之间的关系，并且计算网页重要性的经典算法：PageRank。 PageRank 的简要历史 时至今日，谢尔盖·布林（Sergey Brin）和拉里·佩奇（Larry Page）作为Google 这一雄厚科技帝国的创始人，已经耳熟能详。但在1995 年，他们两人还都是在斯坦福大学计算机系苦读的博士生。那个年代，互联网方兴未艾。雅虎作为信息时代的第一代巨人诞生了，布林和佩奇都希望能够创立属于自己的搜索引擎。1998 年夏天，两个人都暂时离开斯坦福大学的博士生项目，转而全职投入到Google 的研发工作中。他们把整个项目的一个总结发表在了1998 年的万维网国际会议上（WWW7，the seventh international conference on World Wide Web）（见参考文献[1]）。这是PageRank 算法的第一次完整表述。 PageRank 一经提出就在学术界引起了很大反响，各类变形以及对PageRank 的各种解释和分析层出不穷。在这之后很长的一段时间里，PageRank 几乎成了网页链接分析的代名词。给你推荐一篇参考文献[2]，作为进一步深入了解的阅读资料。
PageRank 的基本原理 我在这里先介绍一下PageRank 的最基本形式，这也是布林和佩奇最早发表PageRank 时的思路。 首先，我们来看一下每一个网页的周边结构。每一个网页都有一个“输出链接”（Outlink）的集合。这里，输出链接指的是从当前网页出发所指向的其他页面。比如，从页面A 有一个链接到页面B。那么B 就是A 的输出链接。根据这个定义，可以同样定义“输入链接”（Inlink），指的就是指向当前页面的其他页面。比如，页面C 指向页面A，那么C 就是A 的输入链接。 有了输入链接和输出链接的概念后，下面我们来定义一个页面的PageRank。我们假定每一个页面都有一个值，叫作PageRank，来衡量这个页面的重要程度。这个值是这么定义的，当前页面I 的PageRank 值，是I 的所有输入链接PageRank 值的加权和。 那么，权重是多少呢？对于I 的某一个输入链接J，假设其有N 个输出链接，那么这个权重就是N 分之一。也就是说，J 把自己的PageRank 的N 分之一分给I。从这个意义上来看，I 的PageRank，就是其所有输入链接把他们自身的PageRank 按照他们各自输出链接的比例分配给I。谁的输出链接多，谁分配的就少一些；反之，谁的输出链接少，谁分配的就多一些。这是一个非常形象直观的定义。
C A T I A有限元高级划 分网格教程 -CAL-FENGHAI.-(YICAI)-Company One1
CATIA有限元高级网格划分教程 盛选禹李明志 1.1进入高级网格划分工作台 （1）打开例题中的文件。 （2）点击主菜单中的【开始】→【分析与模拟】→【Advanced Meshing Tools】(高级网格划分工具），就进入【Advanced Meshing Tools】（高级网格划分工具）工作台，如图1－1所示。进入工作台后，生成一个新的分析文件，并且显示一个【New Analysis Case】（新分析算题）对话框，如图1－2所示。 图1－1【开始】→【分析与模拟】→【Advanced Meshing Tools】(高级网格划分 工具） （3）在【New Analysis Case】（新分析算题）对话框内选择【Static Analysis】（静力分析）选项。如果以后打开该对话框的时候均希望是计算静力分 析，可以把对话框内的【Keep as default starting analysis case】（在开始 时保持为默认选项）勾选。这样，下次进入本工作台时，将自动选择静 力分析。 （4）点击【新分析算题】对话框内的【确定】按钮，关闭对话框。 1.2定义曲面网格划分参数 本节说明如何定义一个曲面零件的网格类型和全局参数。 （1）点击【Meshing Method】(网格划分方法)工具栏内的【高级曲面划分】按钮，如图1－3所示。需要在【Meshing Method】(网格划分方法)工 具栏内点击中间按钮的下拉箭头才能够显示出【高级曲面划分】按钮。
有限元网格划分的基本原则 杜平安 《机械设计与制造》 划分网格是建立有限元模型的一个重要环节，它要求考虑的问题较多，需要的工作量较大，所划分的网格形式对计算精度和计算规模将产生直接影响。为建立正确、合理的有限元模型，这里介绍划分网格时应考虑的一些基本原则。 1网格数量 网格数量的多少将影响计算结果的精度和计算规模的大小。一般来讲，网格数量增加，计算精度会有所提高，但同时计算规模也会增加，所以在确定网格数量时应权衡两个因数综合考虑。 图1中的曲线1表示结构中的位移随网格数量收敛的一般曲线，曲线2代表计算时间随网格数量的变化。可以看出，网格较少时增加网格数量可以使计算精度明显提高，而计算时间不会有大的增加。当网格数量增加到一定程度后，再继续增加网格时精度提高甚微，而计算时间却有大幅度增加。所以应注意增加网格的经济性。实际应用时可以比较两种网格划分的计算结果，如果两次计算结果相差较大，可以继续增加网格，相反则停止计算。 图1位移精度和计算时间随网格数量的变化 在决定网格数量时应考虑分析数据的类型。在静力分析时，如果仅仅是计算结构的变形，网格数量可以少一些。如果需要计算应力，则在精度要求相同的情况下应取相对较多的网格。同样在响应计算中，计算应力响应所取的网格数应比计算位移响应多。在计算结构固有动力特性时，若仅仅是计算少数低阶模态，可以选择较少的网格，如果计算的模态阶次较高，则应选择较多的网格。在热分析中，结构内部的温度梯度不大，不需要大量的内部单元，这时可划分较少的网格。 2网格疏密 网格疏密是指在结构不同部位采用大小不同的网格，这是为了适应计算数据的分布特点。在计算数据变化梯度较大的部位(如应力集中处)，为了较好地反映数据变化规律，需要采用比较密集的网格。而在计算数据变化梯度较小的部位，为减小模型规模，则应划分相对稀疏的网格。这样，整个结构便表现出疏密不同的网格划分形式。 图2是中心带圆孔方板的四分之一模型，其网格反映了疏密不同的划分原则。小圆孔附近存在应力集中，采用了比较密的网格。板的四周应力梯度较小，网格分得较稀。其中图b中网格疏密相差更大，它比图a中的网格少48个，但计算出的孔缘最大应力相差1%，而计算时间却减小了36%。由此可见，采用疏密不同的网格划分，既可以保持相当的计算精度，又可使网格数量减小。因此，网格数量应增加到结构的关键部位，在次要部位增加网格是不必要的，也是不经济的。