On the way to achieve minimalism and essentialism

## Month: November, 2014

### Modalverber – kan, skal, vil, må

Infinitiv, Nutid, Datid, Førnutid
at kunne, kan, kunne, har kunnet
at skulle, skal, skulle, har skullet
at ville, vil, ville, har villet
at måtte, må, måtte, har måttet

## at kunne

at kunne udtrykker en evne (ability) eller en mulighed (possibility)
Eks:
Hun kan tale engelsk. (evne)
Han kunne ikke komme til Oles fødselsdag. (mulighed)
Hvad kan der være i vejen med dig? Du er jo helt rød i ansigtet.(mulighed)

## at skulle

at skulle udtrykker en plan (planned future) eller en ordre (order)
skal nok udtrykker et løfte (promise)
Eks:
Jeg skal i biografen kl. 19. (plan)
Du skal være hjemme kl. 16. (ordre)
Jeg skal nok ringe i aften. (løfte)
Min bror skal til lægen kl.13. Han har det ikke så godt. (plan)
Efter en blodprop skal han gå til kontrol hver uge. (ordre)
-Havd skal vi have at spise af grønsager i dag? Broccoli? (plan)
-Det synes jeg ikke! Jeg kan ikke udsta broccoli! (ability – evne) [kan ikke udsta = cannot stand with]

## at ville

at ville udtrykker et ønske (wish) eller en vilje (will)
Eks:
Hun vil gerne være jurist. (ønske)
Han vil ikke bo i København. (vilje)
Vil du ikke have en hovedpinetablet? Jeg tror, det hjælper.(asking for wish, providing suggestion)
Vil du ikke sidde lidt? Du ser ikke ud til at have det så godt. (same above)
Min far ville aldrig gå til lægen før i tiden. (ønske) [før i tiden = in the past]
Vil du være sød at række mig salten? (inquiry)
Nej! For meget salt kan være meget usundt. (mulighed)

## at måtte

at måtte en tilladelse (permission) eller et forbud (ban)
Eks:
Man ikke ryge på skolen (forbud)
I går måtte min kone og jeg tage tidligere hjem. Hun var pludselig blevet dårlig.(tilladelse)
Du sandelig ikke ryge herinde. (ban) [sandelig = indeed]

### A Geometry Trap for SolidWorks FlowSimulation

Geometry check results – Invalid contacts and invalid parts

I have been using SolidWorks Flow Simulation for sometime, and usually, in most cases, it works just fine. However this week, I encountered this small geometry issue which seemingly brought me a big headache.

The first geometry trap (and yeah, there is a second trap blow, just keep reading), as the plot shows above, is making the Flow Simulation cannot find the correct flow domain geometries. By using the Check-Geometry tool provided by the Flow Simulation software, it gives errors called “Invalid contacts” and “Invalid part”.(One will see this is not a leakage issue, if he or she continues reading on.)

This is somehow a little bit strange because the issue is within a sub-assembly, which has been successful  through the air-tight-check on the simple tool FloXpress, done by my colleague. But when I include this sub-assembly in to the top-assembly, the above errors show up while doing geometry check and no flow domain can be obtained… Anyway, all the problems are located in the part connection shown as below:

Problem parts

Note the problem happens on this internal geometry, which also indicates that the previous issue is not a leakage issue, but a geometry error, or invalid geometry. If one make a cut plot and zoom in to the connection where the pipes meet the baffle, one will see some of the intersection parts look like things below (the two figures above):

The idea of drawing the baffle which should be perfectly contact with the pipe is: firstly draw a block with a perfect round top surface (A) which has a diameter exactly as pipe diameter plus shell thickness (above lower figures); secondly make a shell operation through surface (B) and (A).

The reason those parts afterwards don’t contact well have showing up miss-alignments is simply because, some part of the edge of round surface A is connected to some fillets.

Look at the upper pictures on the right side, since there is a fillet surface marked as blue color, when adding a shell performance, the thickness is probably calculated based on the norm direction on the fillet surface thus the shell body will be slightly bent as shown in the red line. This will give a miss-alignment in the model after adding the pipe in.

So in short, the first geometry trap can be concluded as: be special caution while doing a shell performance on a surface which is connected to some fillet or other tilted surfaces.

——————————————————————————————-

Initially, after we saw the above miss-alignment, we decided a quick fix by using the “cavity” tool, simply cut the intersecting parts out from the baffle by using the pipe body.

This solves the problem of “flow geometry not found”. But there is still error or warning messages on some invalid contacts. We didn’t pay attention to that and just went on with the simulation however the following picture is what we got after we started running the simulation:

Yes, you saw it, a software crash or dead…

So here is the second geometry trap – the real trapIf one does not solve ALL the “Invalid contact” or “Invalid parts”, found by the flow simulation geometry check tool, even though one can get the flow domain and proceed with simulation, one may later suffer simulation/software frozen issue…

Also one thing worth mentioning is that, while those invalid contacts exist, it is extremely lagging or time consuming while doing some normal simulation setup operations and geometry check operations. So if you suddenly feel a new model is slow than usual while setting up, there probably might exist those “invalid” stuff in your model. I suggest you fix them first before going any further.

I am not sure whether the second trap can happen in all circumstances but in our case, later on we simply changed the baffle part and make sure the fillet is ended before it touches the boundary of the round surface which is used for guide a shell operation, all problem solved.

So if you have read so far, here is a post written by Christopher Ma –  4 Things to Do Before Every Flow Simulation Analysis. I believe if one follows the process described within this article, make sure all the invalid things are fixed, the chance of software/simulation crash can be minimized.

Thank you for reading so far, hope this article can give you some hints and as always, do have fun with simulations 🙂

### Test post for using Latex in Wordpress

$\LaTeX$ $, is$ it really that easy?

$latex i\hbar\frac{\partial}{\partial t}\left|\Psi(t)\right>=H\left|\Psi(t)\right>&s=2$

$i\hbar\frac{\partial}{\partial t}\left|\Psi(t)\right>=H\left|\Psi(t)\right>$

$latex i\hbar\frac{\partial}{\partial t}\left|\Psi(t)\right>=H\left|\Psi(t)\right>&bg=ffffff&fg=0000ff&s=4$

$i\hbar\frac{\partial}{\partial t}\left|\Psi(t)\right>=H\left|\Psi(t)\right>$

$latex E=mC^2&bg=ffffff&s=3$

$E=mC^2$

A page I use all the time for writing equations by Latex

$E=mC^2$

### A weight function for an engine source sound level empirical equation

Those days I tried to spend some time on making a COMSOL model for calculating the tailpipe radiated noise. One of the first thing to do this is to build up an engine source strength model in to COMSOL. There is already some empirical equation one could get (for example the empirical source strength equation used in the software called SIDLAB).

However during the process I encountered a relatively difficult issue -The empirical equation only give values as the input frequency is a engine firing frequency. If one inputs a random frequency between two engine firing frequencies, one gets a really high and unrealistic value.

In order to make the model of source strength better, a new empirical function is needed, which can considerably drop the sound level between each firing frequencies. To form this new function, I need to develop a weighting function in order to make the empirical engine source sound level equation (upper plot left) to shape more like a real results (upper plot right). Hopefully in the end the original function multiplying the weight_function will give me a good engine source strength model.

In order to achieve this, I started doing some manipulation on a cosine function. Detailed function shaping process can be seen on those pics:

In the end, the weight function can be written as:

W(freq) = 1+(COS(2*Pi*(freq/F1 – 1)) -1) / ( n_low+1+freq/F1*n_fast);

which looks like the following pattern if one uses n_low=4 and n_fast=2, with F1=90;

Note that:

n_low: define how deep weight function can go. Must above 0, recommend 3, 4 or 5, the larger the value, the less deep it goes. In the beginning of the weight function, the first drop can go down from 1 by -2/(n_low+1). In our previous plot case, where n_low=4, this means the early drop of the function can go down to (1-2/(4+1) ) = 0.6.

n_fast: define how fast the weight function disappears (stop oscillating and become as one), must above 1, recommend use 2, the larger the faster it disappears.

In the end, by putting the weight function on the original function (upper plot left), a “nice” looking function is generated (upper plot right).

In the future I will have to take some real engine source data measurement and compare with the output of the function. By tuning n_low and n_fast and other engine parameters used in the original empirical equation, one should be able to get a simple but averagely nicely fitted empirical function.

We will see…