Help understanding simple query trace with 35,000 "query subcube" events

Question

No matter WHAT query I issue against my cube, I'm finding thousands of query subcube events against an unexpected , I assume it's a partition.
Even for the simplest possible query SELECT FROM <CUBE>, which for this cube would return the measure [MRN Distinct Count], a trace reveals 35,000 query subcube events against a partition (?) called "<server>.Medical Home.MedHome.Lab Orders
With Results" which is NOT the partition that holds that [MRN Distinct Count] measure.
I can't figure out why this object is being queried so many times for queries completely unrelated to it.  I believe this performance degradation is somewhat new...so I have been trying to think of what may have been added to the cube recently.
I recently added KPIs and calculated sets & members that DO draw from that Lab Orders With Results object...would calculated members or KPI's cause this kind of problem? I thought that they were all pre-calculated @ processing?
Thanks for any insight you can provide
Here's a summary of the profiler trace on the query SELECT FROM <CUBE>
Event Desc
# of Events
ObjectPath
Duration
Query Begin
1
NULL
0
Query Cube Begin
1
<server>.Medical Home.MedHome
0
Query Subcube Verbose
11
<server>.Medical Home.MedHome.Fact Dx 2
189
Query Dimension
7
<server>.Medical Home.Dim Person
0
Query Subcube Verbose
35650
<server>.Medical Home.MedHome.Lab Orders With Results
13856
Serialize Results Begin
1
<server>.Medical Home.MedHome
0
Serialize Results Current
4
<server>.Medical Home.MedHome
0
Query Subcube Verbose
5
<server>.Medical Home.MedHome.Dim Person
0
Serialize Results Current
1
<server>.Medical Home.MedHome
0
Serialize Results End
1
<server>.Medical Home.MedHome
0
Query Cube End
1
<server>.Medical Home.MedHome
40919
Query End
1
NULL
41059
Paul

Answer 1

RedBirdRising - my cube had several dynamic calculated sets in it.  As I recall several of those sets included slices on that one particular dimension that was being queried so many times. For me it was sets that compiled populations of people
with particular lab result values, so that lab result partition was queried thousands of times for ANY query, even simple ones like SELECT FROM [CUBE].  
To be precise, I actually had calculated sets interacting with calculated measures - for example, one of the offending calculated sets was really this series of calculations:
-CALC SET 1: define calculated set of diabetic patients
-CALC MEASURE 1: define calculated measure for most recent lab test result of a particular lab test - which included a slice on the dimension I found being queried thousands of times.
-DYNAMIC calculated set: FILTER(CALC SET1, CALC MEASURE 1 <= x)
So as soon as I switched that dynamic set to a STATIC set my queries began executing in a reasonable amount of time and those query subcube events were no longer issued in the thousands.  I feel like i've heard that FILTER performs poorly but didn't
know of any alternatives to achieve what we needed.
hope this helps...I can't say I know for sure what unforseen impact(s) switching to static sets has had yet.  Dynamic seemed like the way to go but the performance hit was just too drastic.  
Paul