Thread Subject: Simulink mdl file size bloat

I have a model that I saved a previous version of for
backup purposes. I made a few changes, such as adding a
PSK modulator rather than inputing the signal from the
MATLAB workspace. I also added a few mask parameters to a
subsystem and added some documentation in the form of a
doc block (not much documentation). These seem to be
minor changes, yet the old file's size is 355 KB and the
new file's size is 23.9 MB. Any idea why the size of this
model has gotten so big so fast? The large size of this
model makes working with it more difficult, and I worry
that there may be hidden code that is going to decrease
the performance of my model.

Thanks,
Bryan

The file size is now over 47 MB, having made no changes
besides moving some blocks around to make it look a little
neater. Why is this happening?

I took a look at the .mdl file in Notepad, and the middle
part of the file that looks like line after line of random
characters is where the file is growing significantly. I
was trying to find what the make-up of the .mdl file is to
see if I can tell why this portion of the file is growing,
but I was unable to find information on the structure of
an .mdl.

Any suggestions?

"Bryan " <bdg146.removeThis@gmail.com> wrote in message
<g5fq8u$5r3$1@fred.mathworks.com>...
> The file size is now over 47 MB, having made no changes
> besides moving some blocks around to make it look a
little
> neater. Why is this happening?
>
> I took a look at the .mdl file in Notepad, and the
middle
> part of the file that looks like line after line of
random
> characters is where the file is growing significantly.
I
> was trying to find what the make-up of the .mdl file is
to
> see if I can tell why this portion of the file is
growing,
> but I was unable to find information on the structure of
> an .mdl.
>
> Any suggestions?

what version of matlab/simulink? try saving it as a
different name and cutting out the new blocks you added.
i would guess the doc block might be the problem, but its
only a wild guess. can you tell what is before
the 'random' stuff? Maybe there is a block name or
something there that would point you to where it is.

Thanks for the reply.

To test something, I opened up the model, moved one block
(only moved, no more) and saved the model. It's now over
95 MB. The size of the model appears to double each time
I save it, regardless of what I do to it.

The 'random' stuff that is growing is after all of the
blocks and lines have been defined in the file. In fact,
it's after the model{} portion of the file. It begins:
MatData {
   NumRecords 6
   Data Record { ...
   }
   Data Record { ...
   }
   Data Record { ...
   }
   Data Record { ...
   % LOTS OF JUNK
   }
   Data Record { ...
   }
}

There is some 'junk' in the first 3 data records, but only
a few lines each. Inside the 4th data record is where
there is an enormous amount of data. Each line of 'junk'
beings and ends with a quotation mark (").

What is stored in the 'MatData' and 'Data Record' portions
of this file?

> what version of matlab/simulink? try saving it as a
> different name and cutting out the new blocks you
added.
> i would guess the doc block might be the problem, but
its
> only a wild guess. can you tell what is before
> the 'random' stuff? Maybe there is a block name or
> something there that would point you to where it is.

I forgot to mention what versions I was using. Matlab is
version 7.4.0 (R2007a) and Simulink is version 6.6

I deleted the doc block and saved the model under a
different name and it was still 2x the size of the
original file, so that didn't fix it. I guess I'll go
through and see if I can locate the problem block.

"Bryan " <bdg146.removeThis@gmail.com> wrote in message
<g5fsn3$5v9$1@fred.mathworks.com>...
> Thanks for the reply.
>
> To test something, I opened up the model, moved one
block
> (only moved, no more) and saved the model. It's now
over
> 95 MB. The size of the model appears to double each
time
> I save it, regardless of what I do to it.
>
> The 'random' stuff that is growing is after all of the
> blocks and lines have been defined in the file. In
fact,
> it's after the model{} portion of the file. It begins:
> MatData {
> NumRecords 6
> Data Record { ...
> }
> Data Record { ...
> }
> Data Record { ...
> }
> Data Record { ...
> % LOTS OF JUNK
> }
> Data Record { ...
> }
> }
>
> There is some 'junk' in the first 3 data records, but
only
> a few lines each. Inside the 4th data record is where
> there is an enormous amount of data. Each line
of 'junk'
> beings and ends with a quotation mark (").
>
> What is stored in the 'MatData' and 'Data Record'
portions
> of this file?
>

Apparently the MatData portion of a .mdl file has to do
with the following,
"This version adds a new block parameter, named
UserDataPersistent, that is off by default ...
Simulink encodes the user data as ASCII characters and
saves the encoded data in a new section of the model file
called MatData" [MATLAB Help]

The Data Record causing the trouble has the
label "DataTag2". I traced back in this file (using
Notepad) to a Halfband Filter block, where the UserData
variable is assigned the value "DataTag2".

So, apparently, somehow the UserDataPersistent in this
block got set to true, rather than the default 'false'
value. And I guess it is duplicating this user data
within the halfband filter block for some reason. I could
just change the text in the .mdl file to turn this
parameter off, but I'd rather figure out where this
variable is within Simulink so I can understand why this
happened.

What is this 'user data' being stored and why is it
increasing my file size? How do I change it's value?

"Bryan " <bdg146.removeThis@gmail.com> wrote in message
<g5fsn3$5v9$1@fred.mathworks.com>...
> Thanks for the reply.
>
> To test something, I opened up the model, moved one
block
> (only moved, no more) and saved the model. It's now
over
> 95 MB. The size of the model appears to double each
time
> I save it, regardless of what I do to it.
>
> The 'random' stuff that is growing is after all of the
> blocks and lines have been defined in the file. In
fact,
> it's after the model{} portion of the file. It begins:
> MatData {
> NumRecords 6
> Data Record { ...
> }
> Data Record { ...
> }
> Data Record { ...
> }
> Data Record { ...
> % LOTS OF JUNK
> }
> Data Record { ...
> }
> }
>
> There is some 'junk' in the first 3 data records, but
only
> a few lines each. Inside the 4th data record is where
> there is an enormous amount of data. Each line
of 'junk'
> beings and ends with a quotation mark (").
>
> What is stored in the 'MatData' and 'Data Record'
portions
> of this file?
>
> > what version of matlab/simulink? try saving it as a
> > different name and cutting out the new blocks you
> added.
> > i would guess the doc block might be the problem, but
> its
> > only a wild guess. can you tell what is before
> > the 'random' stuff? Maybe there is a block name or
> > something there that would point you to where it is.
>

They don't look like this???

MatData {
  NumRecords 1
  DataRecord {
    Tag DataTag0
    Data " %)30 . : 8
( 0 % "
"\" $ ! 0 . . 8
( ! % \" $ "
"& 0 0 !@ %=I;F1O=P "
  }
}

The 'Tag' name can be traced to a block in the mdl file
from what i have seen. That would get you to the
offending block. this one happens to be data for a
window function block from the dsp blockset. in that
block's parameters there is:
      DialogControllerArgs "DataTag0"
that must be how simulink finds the right data block.

I would guess that something is corrupted in your setup
and its running away when it saves it.

"David " <dave@bigcompany.com> wrote in message
<g5g1vp$6nf$1@fred.mathworks.com>...
> They don't look like this???
>
> MatData {
> NumRecords 1
> DataRecord {
> Tag DataTag0
> Data " %)30 . : 8
> ( 0 % "
> "\" $ ! 0 . . 8
> ( ! % \" $ "
> "& 0 0 !@ %=I;F1O=P "
> }
> }
>
> The 'Tag' name can be traced to a block in the mdl file
> from what i have seen. That would get you to the
> offending block. this one happens to be data for a
> window function block from the dsp blockset. in that
> block's parameters there is:
> DialogControllerArgs "DataTag0"
> that must be how simulink finds the right data block.
>
> I would guess that something is corrupted in your setup
> and its running away when it saves it.

They all look like that except for one DataRecord. That
DataRecord looks like that for the first few lines and
then it deteriorates into characters seperated by
(usually) four spaces and with plenty of \ and \\ thrown
in.

I've found the offending block to be the halfband filter.
I deleted it, and put a new halfband filter where the old
one was. I saved it off into a temporary file and the
file size immediately shrank. However, after saving it
several times, the same issue was occuring. So I guess a
solution is to replace the halfband filter block every 10
or so times I save this particular model, but that doesn't
explain why this is happening or what can be done to
completely resolve the issue.

"Bryan " <bdg146.removeThis@gmail.com> wrote in message
<g5g33g$i9n$1@fred.mathworks.com>...
> "David " <dave@bigcompany.com> wrote in message
> <g5g1vp$6nf$1@fred.mathworks.com>...
> > They don't look like this???
> >
> > MatData {
> > NumRecords 1
> > DataRecord {
> > Tag DataTag0
> > Data " %)30 . : 8
> > ( 0 % "
> > "\" $ ! 0 . . 8
> > ( ! % \" $ "
> > "& 0 0 !@ %=I;F1O=P "
> > }
> > }
> >
> > The 'Tag' name can be traced to a block in the mdl
file
> > from what i have seen. That would get you to the
> > offending block. this one happens to be data for a
> > window function block from the dsp blockset. in that
> > block's parameters there is:
> > DialogControllerArgs "DataTag0"
> > that must be how simulink finds the right data block.
> >
> > I would guess that something is corrupted in your
setup
> > and its running away when it saves it.
>
> They all look like that except for one DataRecord. That
> DataRecord looks like that for the first few lines and
> then it deteriorates into characters seperated by
> (usually) four spaces and with plenty of \ and \\ thrown
> in.
>
> I've found the offending block to be the halfband
filter.
> I deleted it, and put a new halfband filter where the
old
> one was. I saved it off into a temporary file and the
> file size immediately shrank. However, after saving it
> several times, the same issue was occuring. So I guess
a
> solution is to replace the halfband filter block every
10
> or so times I save this particular model, but that
doesn't
> explain why this is happening or what can be done to
> completely resolve the issue.

that sounds like a reportable bug to me. maybe try
creating a simple model with just that block and a couple
simple sources and sinks and see if it does it then.

"David " <dave@bigcompany.com> wrote in message
<g5g4rm$96d$1@fred.mathworks.com>...
>
> that sounds like a reportable bug to me. maybe try
> creating a simple model with just that block and a
couple
> simple sources and sinks and see if it does it then.

I replaced the halfband filter in my model with a filter
designed with the FDA Tool and all is well.

I can't reproduce the bug in a separate file. I can
reproduce it by re-inserting a halfband filter in my
model, but not by making a new, basic model. There must
be something about my old model that, when coupled with a
halfband filter, is producing this bug. Unfortunately I
don't really have the time to investigate this further,
since reconstructing my model step by step and testing at
each interval could prove to be a lengthy process.

Thanks for all the help!
-Bryan

"Bryan " <bdg146.removeThis@gmail.com> wrote in message
news:g5g9hm$4hb$1@fred.mathworks.com...
> "David " <dave@bigcompany.com> wrote in message
> <g5g4rm$96d$1@fred.mathworks.com>...
>>
>> that sounds like a reportable bug to me. maybe try
>> creating a simple model with just that block and a
> couple
>> simple sources and sinks and see if it does it then.
>
> I replaced the halfband filter in my model with a filter
> designed with the FDA Tool and all is well.
>
> I can't reproduce the bug in a separate file. I can
> reproduce it by re-inserting a halfband filter in my
> model, but not by making a new, basic model. There must
> be something about my old model that, when coupled with a
> halfband filter, is producing this bug. Unfortunately I
> don't really have the time to investigate this further,
> since reconstructing my model step by step and testing at
> each interval could prove to be a lengthy process.

Even if you don't have time to investigate right now, could you please
either set aside a copy of the model for investigation when you do have time
or (if possible) send the model to Technical Support so that the developers
can investigate the cause of this behavior? I'm sure the developers would
like to determine what's causing the file size to increase so dramatically.

--
Steve Lord
slord@mathworks.com

On Jul 14, 1:31=A0pm, "Bryan " <bdg146.removeT...@gmail.com> wrote:
> "David " <d...@bigcompany.com> wrote in message
>
> <g5g4rm$96...@fred.mathworks.com>...
>
>
>
> > that sounds like a reportable bug to me. =A0maybe try
> > creating a simple model with just that block and a
> couple
> > simple sources and sinks and see if it does it then. =A0
>
> I replaced the halfband filter in my model with a filter
> designed with the FDA Tool and all is well.
>
> I can't reproduce the bug in a separate file. =A0I can
> reproduce it by re-inserting a halfband filter in my
> model, but not by making a new, basic model. =A0There must
> be something about my old model that, when coupled with a
> halfband filter, is producing this bug. =A0Unfortunately I
> don't really have the time to investigate this further,
> since reconstructing my model step by step and testing at
> each interval could prove to be a lengthy process.
>
> Thanks for all the help!
> -Bryan

Bryan,
I'd look through the callback M file for that block. I'd once found a
similar bug in another block where instead of replacing the mask
display parameter the block would append to the existing string
causing it to grow. Sounds like this block is doing something similar,
it's attaching data to the UserData field and appending to it every
time the callback is called. If you have access to the M file then try
to determine whether the block really needs access to persistent user
data. For instance, if the block is not making use of the old user
data entries you can fix this problem by turning off
UserDataPersistent for that block using set_param. Also, make sure you
report this to the Mathworks.

HTH,
Ashish.

"Steven Lord" <slord@mathworks.com> wrote in message
<g5gb1f$kfi$1@fred.mathworks.com>...
>
> Even if you don't have time to investigate right now,
could you please
> either set aside a copy of the model for investigation
when you do have time
> or (if possible) send the model to Technical Support so
that the developers
> can investigate the cause of this behavior? I'm sure
the developers would
> like to determine what's causing the file size to
increase so dramatically.
>
> --
> Steve Lord
> slord@mathworks.com


Would you prefer that I email it to you directly or go
through the correct channel on the Mathworks website?

"Bryan " <bdg146.removeThis@gmail.com> wrote in message
news:g5is7a$80p$1@fred.mathworks.com...
> "Steven Lord" <slord@mathworks.com> wrote in message
> <g5gb1f$kfi$1@fred.mathworks.com>...
>>
>> Even if you don't have time to investigate right now,
> could you please
>> either set aside a copy of the model for investigation
> when you do have time
>> or (if possible) send the model to Technical Support so
> that the developers
>> can investigate the cause of this behavior? I'm sure
> the developers would
>> like to determine what's causing the file size to
> increase so dramatically.
>>
>> --
>> Steve Lord
>> slord@mathworks.com
>
>
> Would you prefer that I email it to you directly or go
> through the correct channel on the Mathworks website?

Please send it to Technical Support. I don't work with Simulink very often,
so it's more likely they'd know what's going on or be able to determine
what's causing this behavior.

--
Steve Lord
slord@mathworks.com

Bug report submitted. Thanks everyone for the help.