In a STEP file I generated with OpenCascade, I can see this:
#58 = VERTEX_POINT('',#59);
#59 = CARTESIAN_POINT('',(-0.5,-0.5,-0.5));
#60 = VERTEX_POINT('',#61);
#61 = CARTESIAN_POINT('',(0.5,-0.5,-0.5));
#62 = SURFACE_CURVE('',#63,(#67,#79),.PCURVE_S1.);
#63 = LINE('',#64,#65);
#64 = CARTESIAN_POINT('',(-0.5,-0.5,-0.5));
#65 = VECTOR('',#66,1.);
#66 = DIRECTION('',(1.,0.,0.));
#67 = PCURVE('',#68,#73);
The repetition of data #59 and #64 annoys me a bit.
Seems like this STEP file could be a bit smaller (particularly if there thousand of vertices).
And when I edit the file to use #59 where #64 is used, it still looks fine.
Is there a good reason to have this duplicated data?
And more important, is there a way to avoid it?
I already tried creating a TopoDS_Vertex for each vertex and avoid repeating TopoDS_Edges that connect the same two vertices.
Those edges are then used to create a TopoDS_Wire, which in turn is used to create TopoDS_Face.
The whole mesh is put together with a BRepBuilderAPI_Sewing.
Thanks
My answer is just a guess!
The two Cartesian points #59 and #64 are by chance identical, but different geometric entities are being built upon them. Obviously the surface curve #62 referring to the line #63 referring to the Cartesian point #64 could also refer to point #59.
But what should happen, if someone opens the STEP file and wants to modify the coordinates of vertex #58 which are stored in the Cartesian point #59? Should the line #63 and surface curve #62 also be modified? Or should they be redefined? Why should modification of vertex #58 cause a redefinition of another entity that shares only by chance one Cartesian position?
Therefore I guess that your proposal would be some kind of "STEP format compression", but the actual intention is the clean definition of hierarchies of geometric entities.
Related
I have a very large panel data and would like to apply a number of simple machine learning techniques in Matlab (Logistic Regression, Decision Trees, Bagged Trees).
During my preparation I came across fitglm and fitLifetimePDModel, the latter of which is meant to capture panel data. I was trying to understand how/if that differs from fitglm because when I try the below, the results are exactly the same.
Why is that? For example, under fitglm I'm not telling the program that each customer can have more than one data points.
load RetailCreditPanelData.mat
pdModel_1 = fitLifetimePDModel(data,"Logistic", 'AgeVar','YOB', 'IDVar','ID', 'LoanVars','ScoreGroup','ResponseVar','Default');
disp(pdModel_1.Model)
pdModel_2 = fitglm(data,'Default ~ 1 + ScoreGroup + YOB', 'Distribution','binomial', 'link', 'logit');
disp(pdModel_2)
I am currently working on a storage tank heated with an internal hot water coil.I need to know how does the temperature distribution look like in the tank.
I have tried the steady state model in Matlab, but I Don't find it very precise ( I can only enter thermal conductivities of the product and the tank material + Boundary conditions ) In my opinion, this makes the distribution too generic and not specific to my case. I also tried the transient model and but there are some errors while running the code.
Here's the code I used for the transient model ( I am new to Matlab, so please excuse any code errors)
model = createpde('thermal','transient');
geo = multicylinder([3.4,3.5],7.1)
model.Geometry= geo;
pdegplot(model,'FaceLabels',"on")
generateMesh(model);
pdemesh(model)
thermalProperties(model,"Cell",2,"ThermalConductivity",0.1,"MassDensity",576,"SpecificHeat",0.5)
thermalProperties(model,"Cell",1,"MassDensity",932,"SpecificHeat",2.28,"ThermalConductivity",0.12)
thermalIC(model,0)
tlist=0:.1:5
Thermalresults = solve(model,tlist);
u= Thermalresults.Temperature
pdeplot3D(model,'ColorMapData', u)
first a little background. I'm a psychology student so my background in coding isn't on par with you guys :-)
My problem is as follow and the most important observation is that curve fitting with 2 different programs gives completly different results for my parameters, altough my graphs stay the same. The main program we have used to fit my longitudinal data is kaleidagraph and this should be seen as kinda the 'golden standard', the program I'm trying to modify is matlab.
I was trying to be smart and wrote some code (a lot at least for me) and the goal of that code was the following:
1. Taking an individual longitudinal datafile
2. curve fitting this data on a non-parametric model using lsqcurvefit
3. obtaining figures and the points where f' and f'' are zero
This all worked well (woohoo :-)) but when I started comparing the function parameters both programs generate there is a huge difference. The kaleidagraph program stays close to it's original starting values. Matlab wanders off and sometimes gets larger by a factor 1000. The graphs stay however more or less the same in both situations and both fit the data well. However it would be lovely if I would know how to make the matlab curve fitting more 'conservative' and more located near it's original starting values.
validFitPersons = true(nbValidPersons,1);
for i=1:nbValidPersons
personalData = data{validPersons(i),3};
personalData = personalData(personalData(:,1)>=minAge,:);
% Fit a specific model for all valid persons
try
opts = optimoptions(#lsqcurvefit, 'Algorithm', 'levenberg-marquardt');
[personalParams,personalRes,personalResidual] = lsqcurvefit(heightModel,initialValues,personalData(:,1),personalData(:,2),[],[],opts);
catch
x=1;
end
Above is a the part of the code i've written to fit the datafiles into a specific model.
Below is an example of a non-parametric model i use with its function parameters.
elseif strcmpi(model,'jpa2')
% y = a.*(1-1/(1+(b_1(t+e))^c_1+(b_2(t+e))^c_2+(b_3(t+e))^c_3))
heightModel = #(params,ages) abs(params(1).*(1-1./(1+(params(2).* (ages+params(8) )).^params(5) +(params(3).* (ages+params(8) )).^params(6) +(params(4) .*(ages+params(8) )).^params(7) )));
modelStrings = {'a','b1','b2','b3','c1','c2','c3','e'};
% Define initial values
if strcmpi('male',gender)
initialValues = [176.76 0.339 0.1199 0.0764 0.42287 2.818 18.52 0.4363];
else
initialValues = [161.92 0.4173 0.1354 0.090 0.540 2.87 14.281 0.3701];
end
I've tried to mimick the curve fitting process in kaleidagraph as good as possible. There I've found they use the levenberg-marquardt algorithm which I've selected. However results still vary and I don't have any more clues about how I can change this.
Some extra adjustments:
The idea for this code was the following:
I'm trying to compare different fitting models (they are designed for this purpose). So what I do is I have 5 models with different parameters and different starting values ( the second part of my code) and next I have the general curve fitting file. Since there are different models it would be interesting if I could put restrictions into how far my starting values could wander off.
Anyone any idea how this could be done?
Anybody willing to help a psychology student?
Cheers
This is a common issue when dealing with non-linear models.
If I were, you, I would try to check if you can remove some parameters from the model in order to simplify it.
If you really want to keep your solution not too far from the initial point, you can use upper bounds and lower bounds for each variable:
x = lsqcurvefit(fun,x0,xdata,ydata,lb,ub)
defines a set of lower and upper bounds on the design variables in x so that the solution is always in the range lb ≤ x ≤ ub.
Cheers
You state:
I'm trying to compare different fitting models (they are designed for
this purpose). So what I do is I have 5 models with different
parameters and different starting values ( the second part of my code)
and next I have the general curve fitting file.
You will presumably compare the statistics from fits with different models, to see whether reductions in the fitting error are unlikely to be due to chance. You may want to rely on that comparison to pick the model that not only fits your data suitably but is also simplest (which is often referred to as the principle of parsimony).
The problem is really with the model you have shown resulting in correlated parameters and therefore overfitting, as mentioned by #David. Again, this should be resolved when you compare different models and find that some do just as well (statistically speaking) even though they involve fewer parameters.
edit
To drive the point home regarding the problem with the choice of model, here are (1) results of a trial fit using simulated data (2) the correlation matrix of the parameters in graphical form:
Note that absolute values of the correlation close to 1 indicate strongly correlated parameters, which is highly undesirable. Note also that the trend in the data is practically linear over a long portion of the dataset, which implies that 2 parameters might suffice over that stretch, so using 8 parameters to describe it seems like overkill.
I am attempting to write some NEON code for optimal filling of word arrays on iPhone/iPad. What is so very strange about this issue is that the code seems to jump into a function named _ARCLite_load when a NEON instruction assigns a value to q3. Has anyone seen something like this before:
(test_time_asm.s compiled with xcode 4.6 and the -no-integrated-as flag)
.section __TEXT,__text,regular
.section __TEXT,__textcoal_nt,coalesced
.section __TEXT,__const_coal,coalesced
.section __TEXT,__picsymbolstub4,symbol_stubs,none,16
.text
.align 2
.globl _fill_neon_loop1
.private_extern _fill_neon_loop1
_fill_neon_loop1:
push {r4, r5, r6, r7, lr}
// r0 = wordPtr
// r1 = inWord
// r2 = numWordsToFill
mov r2, #1024
// Load r1 (inWord) into NEON registers
vdup.32 q0, r1
vdup.32 q1, r1
vdup.32 q2, r1
vdup.32 q3, r1 (Stepping into this instruction jumps into __ARCLite__load)
NEONFILL16_loop1:
vstm r0!, {d0-d7}
sub r2, r2, #16
cmp r2, #15
bgt NEONFILL16_loop1
mov r0, #0
pop {r4, r5, r6, r7, pc}
.subsections_via_symbols
Single stepping through the ASM instructions work up until the instruction that assigns to q3. When I step over that instruction, the code seems to jump here:
(gdb) bt
#0 0x0009a568 in __ARCLite__load () at /SourceCache/arclite_iOS/arclite-31/source/arclite.m:529
#1 0x0007b050 in test_time_run_cases () at test_time.h:147
This is really strange and I am really quite at a loss to understand why assigning to a NEON register would cause this. Does NEON use q3 for something special that I am unaware of?
I also tried to load up the registers using dN (64 bit regs), with the same results on assignment to d7.
vdup.32 d0, r1
vdup.32 d1, r1
vdup.32 d2, r1
vdup.32 d3, r1
vdup.32 d4, r1
vdup.32 d5, r1
vdup.32 d6, r1
vdup.32 d7, r1
(later)
After messing around with the suggested changes, I found the root cause of the problem. It was this branch label:
NEONFILL16_loop1:
vstm r0!, {d0-d7}
sub r2, r2, #16
cmp r2, #15
bgt NEONFILL16_loop1
For some reason, the branch label was causing a jump to another location in the code. Replacing the label above with the following fixed the problem:
1:
vstm r0!, {d0-d7}
sub r2, r2, #16
cmp r2, #15
bgt 1b
This could be some weird thing with the version of the ASM parser in clang delivered with xcode 4.6, but anyway just changing the label fixed it.
q3 is neither assigned to some special roles nor needs to be preserved. Don't worry about this.
I think auselen is right with his guess. Just looking at the disassembly will make it clear.
Try this below though :
.section __TEXT,__text,regular
.section __TEXT,__textcoal_nt,coalesced
.section __TEXT,__const_coal,coalesced
.section __TEXT,__picsymbolstub4,symbol_stubs,none,16
.text
.align 2
.globl _fill_neon_loop1
.private_extern _fill_neon_loop1
_fill_neon_loop1:
// r0 = wordPtr
// r1 = inWord
// r2 = numWordsToFill
mov r2, #1024
// Load r1 (inWord) into NEON registers
vdup.32 q0, r1
vdup.32 q1, r1
vdup.32 q2, r1
vdup.32 q3, r1
subs r2, r2, #16
bxmi lr
NEONFILL16_loop1:
vstm r0!, {d0-d7}
subs r2, r2, #16
bpl NEONFILL16_loop1
mov r0, #0
bx lr
.subsections_via_symbols
I removed the obsolete register preserving completely in addition to the cmp within the loop. (You know, I HAVE to optimize everything :))
If auselen's guess is right, this might have changed the tracing timing and stepping into ARClite will occur at a later point.
Almost every time I've jumped somewhere strange in handwritten ARM code it's been because I've fumbled the thumb interworking and the function has been executing in the wrong mode -- consequently the instruction stream looks like garbage to the CPU, and it jumps about randomly until it hurts itself and falls over.
For all labels which are function entrypoints, you should have this assembly directive:
.type _fill_neon_loop1, %function
This tells the linker that when it fixes up BL instructions, or when it computes the address of the function, it should make appropriate adjustments to ensure it's executed in the correct mode.
I am writing a test bench for Ripple counter using d flip flop. My program is compiling without errors, however, I get undefined result. How can I solve this problem?
Here is the code:
module RCounter;
reg d,d2,d3,d4,clk;
wire q,q2,q3,q4;
DFlipFlop a(d,q,clk);
DFlipFlop a1(d2,q2,q);
DFlipFlop a2(d3,q3,q2);
DFlipFlop a3(d4,q4,q3);
initial
begin
clk =1;
d=0;d2=0;d3=0;d4=0;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
#2 d=0;d2=~q2; d3=~q3; d4=~q4;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
#2 d=0;d2=~q2; d3=~q3; d4=~q4;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
#2 d=0;d2=~q2; d3=~q3; d4=~q4;
#2 d=1;d2=~q2; d3=~q3; d4=~q4;
end
always
begin
#2 assign clk = ~ clk;
end
endmodule
What am I doing wrong and how can I solve this?
What you have there is not a ripple counter, and it seems that you don't really understand the boundary between your testbench and your DUT (design under test, or in your case, the 'ripple counter').
What you have is a testbench that is simulating four independent flip flops. If you were simulating a ripple counter, you should have a module called something like 'RCounter', which is instanced inside something else called 'RCounter_TB'. The testbench should only drive the inputs (for a counter, clock and reset), it should not drive the d pins of the individual flops, as the connections between these flops is what you want to test.
Inside the ripple counter module, you define the wired connections between your flip flops. There should not be any # time delays inside this module, because a module does not have a concept of fixed time delays. If you want the d2 pin to be driven from ~q2, then you just assign it as such:
assign d2 = ~q2
Because in hardware, this is just a wire looping back from the output of ~q2 back to d2. It always exists, and it has no concept of time.
As to specifically why you're getting X's on your output, I'll guess that it comes from the flip flop design you posted in your last question.
module DFlipFlop(d,q,clk);
input d,clk;
output q;
assign q = clk?( (d==1)? 1:0) : q;
endmodule
This is not a flip flop, as there is no state retention here, it's just an assign statement with an infinite feedback loop, (you essentially just have a wire driving itself).
If you want to model a flip flop, you need to use an always #(posedge clk) block, to imply that you want some state retention. I'll leave it to you to look up how to use an always block to model a flip flop.